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Abstract 


There  is  a  growing  need  to  develop  flexible, 'robust  avionics  to  meet  ever  changing  mission  needs  of  the  operational  forces.  Such 
needs  may  conflict  with  other  characteristics  required  such  as  standardisation,  increased  reliability,  durability  and  integrity. 
Weapon  system  costs  and  associated  avionics  costs  continue  to  increase  while  military  budgets  continue  to  shrink  due  to 
changing  world  conditions  Thus  it  is  even  more  important  to  intelligently  resolve  these  often  conflicting  forces  driving 
development  efforts 

These  evolving  trends,  conflicts  and  challenges  will  be  examined  in  this  Lecture  Senes  with  a  view  to  enhancing  dialogue, 
understanding  and  improved  planning. 

Tins  Lecture  Series,  sponsored  by  the  Avionics  Panel  of  AGARD,  h.as  been  implemented  by  the  Consultant  and  Exchange 
Programme 


Abrege 


Des  equipements  d'avionique  adaptatifs  et  robusles  soni  de  plus  en  plus  demandes  pour  faire  face  it  revolution  permanente  ties 
besoms  exprinies  par  les  forces  operationnelles  Or,  il  se  peut  que  dc  lels  besoms  soicnt  cn  contradiction  avec  d'amres 
specifications  qui  sont  demandees,  telles  que  la  standardisation,  la  fiabiliic  rcuforcee.  la  daree  de  vie  ei  rmlegrite 

Les  couts  des  systemes  d'armes  et  ceux  des  sysiemes  d’avionique  associes  continucnt  a  griinper,  tandis  que  les  budgets  militaires 
ne  cessent  de  dimmuer  en  raison  de  la  situation  politique  mondiale  11  esi  done  ii  fortiori  neccssaire  de  resoudre  intelligemmeni 
les  donnees  souvent  contradictoires  qui  sont  a  la  base  de  rorientalion  des  efforts  de  dcveloppemcnt  dans  cc  domaine. 

Ces  tendances,  ces  contlits  et  ces  defis  seroiil  examines  lor.s  de  ce  cycle  de  conferences,  en  vuc  de  favoriser  Ic  dialogue,  de 
facililcr  la  comprehension  et  d'amchorcr  la  planification. 

Ce  cycle  de  co  ifcrences  esI  presente  dans  le  cadre  du  programme  des  Consultants  et  des  Echanges,  .vous  I'egide  du  Panel 
AGARD  d'Avionique. 
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SUMMARY: 

This  paper  describes  the  evolution  of  avionic  systems 
architectures  in  U.S.  Air  Force  fighter  aircraft,  beginning  with 
the  system  design  typical  of  the  "Century  Series”  aircraft  (the 
F-lOO,  F-101,  etc.)  and  progressing  on  through  the  long  list  of 
fielded  aircraft  to  the  front-line  fighters  of  today  and  beyond  to 
the  systems  currently  under  development  at  the  Aeronauucal 
Systems  Division.  In  parallel  with  this  description,  the  forcing 
functions  and  catalysts  for  change  of  avionic  systems 
architecture  am  also  noted.  In  this  regard,  the  rapid  shift  to 
digital  avionics  made  possible  by  the  transistor  and  the 
integrated  circuit,  wafer-scale  integration,  and  high-density 
mass  memory  devices  has  rapidly  driven  the  evolution  of 
avionic  system  architecture.  Attendant  with  such  technology 
advancements,  pilot  interface  associated  with  each  new 
generation  of  avionic  subsystem  has  also  continued  to  mature 
and  thts  also  has  had  a  major  impact  on  system  design.  With 
the  ever-increasing  capabilities  of  weapons  systems,  pilot 
workload  has  increased  dramatically.  The  ne^  for 
simplification,  integration,  and  automation  of  operator 
functions  has  become  abundantly  clear.  The  evolution  of 
system  design  features  intended  to  ease  the  operator's  burden 
have  greaUy  influenced  system  design,  and  these  impacts  are 
also  reviewed.  In  conclusion,  a  quick  glimpse  at  future  means 
of  supporting  the  pilot  is  provided  and  the  implications  on 
future  avionic  system  design  reviewed. 

PREFACE: 

The  purpose  of  this  paper  is  to  document  the  evolunon  of 
avionic  systems  architecture,  as  well  as  the  forcing  functions 
responsible  for  most  significant  changes  in  fighter  aircraft 
designs  over  the  past  40  years.  The  paper  will  also  address  the 
emerging  technologies  which  are  affecting  our  cum  n,  avionic 
system  design  development  activities,  as  well  as  a- .  cipated 
architecture  issues  in  systems  to  be  fielded  throug  iout  the 
current  decade. 

INTRODUCTION: 

As  an  introduction  to  avionics  architecrate,  let’s  first  begin 
with  a  definition:  avionics  architecture  is  that  top  level  system 
design  characteristic  which  best  describes  ihe  manner  in  which 
system-level  functions  have  been  defined  and  implemented, 
allocated  to  subsystems  and  integrated  into  the  v/hole,  such 
that  predetermined  objectives  and  operational  needs  may  be 
satisfied.  Architectures  may  be  broadly  described  as' 

(a)  FEDERATED  ARCHITECTURE.  Systems 
composed  of  many  “stand  alone"  subsystems,  wherein 
each  subsystem  is  highly  dependent  upon  the  operator  for 
management  (data  inputs)  and  control  (operating  mode 
selection).  The  operator  must  continually  gather  outputs 
from  each  subsystem,  develop  and  maintain  an  awareness 


of  total  weapon  system  state,  and  make  system-level 
decisions  regarding  mission  objectives  and  execution. 

(b)  INTEGRATED  ARCHITECTURE.  Many 
functions  performed  autonomously  wuhi.i  a  system/ 
subsystem,  with  well-defined  means  for  all  subsystem 
interactions.  Little  need  for  direct  operator  intervention  or 
management  of  subsystems,  except  for  high-level 
decisions  affecung  realization  of  mission  objectives. 

(c)  HYBRID  ARCHITECTURE.  System  designs 
possessing  both  federated  and  integrated  design 
charactensnes,  containing  mixtures  of  "stand  alone” 
subsystems  and  clusters  of  locally  integrated  subsystems 
(supporting  common,  dedicated  functions). 

It  is  important  to  note  that  pilot  performance  plays  a  very 
significant  role  in  system  design.  The  pilot’s  activities  and 
functions  must  ultimately  be  integrated  before  total  system 
performance  may  be  realized.  Because  of  the  attention 
required  of  the  pilot  in  federated  designs,  and  ultimately 
because  of  the  continually  increasing  repenoue  of  capabilities 
and  related  numbers  of  avionic  subsystems  in  each  new 
generation  of  fighter  aircraft,  the  trend  has  been  strongly 
toward  in'egrated  system  architectures.  Such  systems  greatly 
relieve  pilot  workload  and  permit  better  focus  on 
accomplishment  of  mission  objectives.  As  will  be  seen,  there 
are  a  myriad  of  ways  and  means  to  satisfy  mission  objectives 
.and  ever  advancing  technology  has  had  a  major  impact  on 
system  designs.  This  may  be  best  illustrated  by  beginning  with 
the  typical  system  architecture  of  the  Century  Series  fighters 
of  the  1950’s,  and  describing  the  evolution  of  avionic  system 
architecture  to  date. 

THE  I9S0’s: 

In  die  “Ontury  Senes”  fighter  aircraft  (the  F-IOO,  F-IOI, 
etc.)  of  this  era,  the  typical  avionics  system  architecture  was  a 
federated  design.  Most  avionic  subsystems  designs  were 
isolated,  stand-alone  equipments  ( see  Figure  1 ).  They  were 
largely  based  upon  vacuum  tube  technology,  employing 
analog  (or  discrete)  interfaces  with  dedicated  controls  and 
displays.  The  pilot  was  tlie  principal  integrator,  gathering 
information  from  a  multitude  of  sources  md  exercising  system 
control  through  manipulation  of  toggle- switches  or  stacked 
wafer  (Ledex)  switches.  Because  of  the  large  number  of 
discrete  components  (transistors,  resistors,  connectors,  etc.), 
most  subsysterps  designs  could  not  perform  reliably 
throughout  the  variety  of  variety  of  operating  environments. 
These  avionic  subsystei  is  were  also  quite  heavy  and  required 
significant  allocations  of  volume  (which  has  always  been 
extremely  limited  in  flghter  aircraft).  These  characteristics 
have  been  succinctly  described  by  Longbrake  (Ref.  1)  in  his 
paper  on  “Avionics  Acquisition,  Trends  and  Future 
Approaches”.  Specific  details  and  trends  have  been  aptly 
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TYPICAL  CENTURY-SERIES  AIRCRAFT:  F-100,  F-101,  ETC.  (19S0) 
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captured  in  figures  developed  by  Longbrake,  two  of  which 
have  been  extracted  from  his  paper  and  included  here  for 
reference  (Figures  2  and  3).  And  finally,  these  subsystems 
were  fiequendy  difficult  to  integrate  electrically  due  to 
instabilities  associated  with  analog  signals.  For  all  of  these 
reasons,  there  was  little  or  no  backup  or  system  redundancy, 
and  It  was  incumbent  upon  the  pilot  to  gather  and  interpret 
available  information  from  his  limited  avionics  suite  to  control 
the  air  vehicle,  to  maintain  situational  awareness,  and  to 
perform  his  assigned  mission.  With  this  limited  repertoire  of 
system  capabilities,  the  pilot  was  able  to  assimilate  all 
necessary  informauon  -  and  could  do  so  quite  reliably,  given 
sufficient  training  and  experience.  The  greatest  chink  ui  the 
armor  was  the  low  reliability  of  avionics  systems  (typically  on 
the  order  of  10  hours  MTBR,  and  the  inability  to  accept 
failure  of  a  critical  avionic  subsystem  without  affecting 
mission  success. 

THE  I960’s: 

During  this  era,  existing  avionic  systems  capabilities  began 
to  mature  and  most  importanUy,  solid-state  technology  was 
introduced.  The  reliability  of  many  avionic  subsystems  began 
to  improve  dramatically  as  use  of  the  transistor  became  the 
norm.  In  addition,  significant  advances  in  operational 
capability  were  realired  by  the  introduction  of  new  avionic 
subsystems  such  as  the  inertial  navigation  system,  radar 
systems,  and  the  head-up  display.  However,  the  pilot  was 
becoming  more  and  more  burdened  as  additional  subsystems 
and  funcDons  were  added,  and  the  list  of  operator  tasks 
associated  with  avionic  systems  began  to  grow.  The  need  to 
integrate  or  consolidate  many  avionic  subsystems  into  larger, 
more  manageable  and  efficient  units  began  to  be  lecognized 
and  hybrid  avionic  system  architectures  began  to  emerge.  Two 


good  examples  of  such  efforts  to  control  pilot  workload  were 
the  “Fbght  Director  System"  (FDS)  and  the  “Head-Up 
Display”  (HUD)  (see  Figure  4).  In  the  FDS,  a  multitude  of 
individual  cockpit  instruments  (attitude  indicator,  compass, 
angle  of  attack  indicator,  radio  navigation  indicauir,  etc.)  were 
integrated  into  two  primary  instruments:  the  Attitude  Director 
Indicator  and  the  Horizontal  Situation  Indicator.  In  addition, 
the  FDS  presented  command  steering  cues  which  greatly 
leduced  the  burdens  associated  with  radio  navigation  and 
instrument  landing.  Similar  capabilities  were  consolidated  into 
the  HUD,  which  permitted  the  pilot  to  gain  necessary  control 
information  while  keeping  his  eyes  out  of  the  cockpit  (looking 
for  identifiable  landmarks,  targets,  adversaries,  and  conflicting 
traffic,  while  maintaining  formation  position).  Witli  increasing 
use  of  the  transistor,  system  weight  and  volume  requirements 
would  have  been  expected  to  be  reduced;  however,  the  greatly 
improved  operational  performance  offered  by  newer 
subsystems  such  as  the  inertial  navigation  system,  radar,  and 
HUD  caused  system  weight  and  volume  allocations  to 
continue  to  grow  (although  at  a  somewhat  reduced  rate). 
System  architectures  remained  largely  of  federa'ed  design,  and 
as  in  the  previous  era,  there  was  little  opportunity  to  improve 
system  robiismess  or  offer  system  redundancy. 

THE  1970’s: 

In  this  era  the  transition  to  digital  avionics  was  fully 
realized.  Troly  integrated  system  architectures  began  to 
emerge,  and  dependence  upon  the  digital  data  bus  began  (see 
example,  in  Figure  5).  More  importantly,  avionics  began  to  be 
employed  in  flight  critical  appheations  (electronic  flight 
controls  and  terrain  following  systems).  Sensor  and  system 
capabilities  continued  to  increase  dramatically,  including 
smart  stores  and  associated  management  systems. 
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Nighl/all-v  eather  capabilities  began  to  be  realized. 
Avionics  weight  and  volume  allocations  began  to  level  off, 
primanly  due  to  inability  of  the  pilot  to  accept  increased 
workload  associated  with  the  management  of  additional 
avionic  subsystems.  System  architectures  became  highly 
integrated,  and  the  use  of  shared  time  division  multiplexed 
digital  data  buses  (MIL-STD-1553)  became  the  norm.  It  was 
during  this  era  that  the  full  impact  of  the  “information 
overload”  in  the  cockpit  began  to  be  recognized.  The  ability  of 
the  pilot  to  properly  select  and  interpret  necessary  information, 
and  to  manage  his  weapon  system  in  such  manner  as  to  realize 
Its  full  potential,  became  recognized  as  a  hmiting  factor  and  a 
significant  problem  winch  requued  resolution  before 
additional  capabilities  could  be  supported. 

THE  1980’s: 

III  this  era  very  few  new  fighter  aircraft  designs  emerged: 
instead,  the  capabilities  of  existing  aircraft  were  substantially 
improved  and  upgraded,  including  the  upgrading  of  avionic 
systems.  Digital,  highly  uitegiated  avionic  systems  were 
optimized  to  the  extent  that  technology  allowed.  A  good 
example  is  the  F-16C/D  architecture  (Figure  6),  one  of  many 
examples  illusuated  in  the  Multiplex  Applications  Handbook 
(Ref.  2).  Pilot  workload  issues  were  fully  recognized  by  Jean 
R.  Gebman  (Ref.  3)  and  others,  and  inroads  were  made  on 
easing  management  and  control  of  avionic  systems.  Controls 
were  optimized  such  that  with  minimal  switch-throws  or  key 
strokes,  a  single  mode  of  operauon  could  be  selected  (with 
many  lower-tier  control  actions  performed  automatically, 
under  computer  control).  For  example,  a  simple  selection  of 
ground  attack  mode  would  automatically  prepare  the  radar. 


HUD,  stores,  and  the  flight  control  system  for  this  specific 
mission  segment.  Large  scale  integration  computing  devices/ 
chips  enabled  a  much  greater  degree  of  automation,  while 
system  weight  and  volume  reouirements  remained  essentially 
constant.  Since  physical  size  oi  processors  was  beginning  to 
shrink,  we  could  now  afford  to  build  in  some  redundancy  to 
gain  system  robusmess.  However,  it  became  fully  apparent 
that  if  maximum  advantage  were  to  be  taken  of  emerging 
sensor  technologies,  further  automation  of  sensor  system 
management  would  be  required.  Because  of  the  complexity  of 
such  avionic  systems,  reliability  and  maintenance  issues  began 
to  loom  ever  larger.  While  the  reliability  of  individual 
subsystems  became  much  greater  (due  to  the  reduced  number 
of  electronic  components  and  interconnections  within 
subsystems),  the  ever  growing  number  of  subsystems  began  to 
impact  overall  system  reliability.  The  determination  of  fault 
modes  and  failure  locations  became  ever  more  difficult, 
impacting  maintenance  activities  and  operational  readiness  of 
aircraft.  With  the  development  of  Very  High  Speed  Integrated 
Circuit  (VHSIC)  chips,  the  enormity  of  the  software 
development  task  also  began  to  be  felt.  With  the  emergence  of 
immense  processing  capabilities  among  various  subsystems, 
the  difficulties  related  to  parallel  processing,  time  dependence, 
and  data  correlation  (i.e.,  data  latency)  within  the  avionic 
system  became  a  significant  issue.  By  the  end  of  this  era  it 
became  apparent  that  significant  changes  in  avionic  system 
architecture  would  be  necessary  if  we  were  to  take  full 
advantage  of  the  new  sensor  technology  (electronically 
scanned  arrays),  high-throughput  computing  devices,  and 
wafer-scale  integration  tec’nmques/surface  mount  technology 
just  beginning  to  emerge. 
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ADVANCED  F-16  SYSTEM  ARCHITECTURE 

ITi^un  6 


THE  CURRENT  DECADE  (1990’s); 

The  systems  architectures  in  the  beginning  of  this  eta  are 
excmplined  by  the  preliminary  design  activities  ongoing  in  the 
Advanced  Tacacal  Fighter  (ATF)  program.  Due  to  the  severe 
pressures  on  the  defense  R&D  budget,  Congress  mandated 
that  the  Tn-Services  (Army,  Navy,  and  Air  Force)  agree  on 
standardized  approaches  to  the  development  of  advanced 
systems  architectures  for  the  next  generaaon  of  tacacal 
aircraft,  including  the  Army’s  “Light  Helicopter"  (LH), 

Navy’s  “Advanced  Tactical  Aircraft"  (ATA),  and  the  Air 
Force’s  ATF.  This  activity  is  ongoing  within  the  Tn-Service 


sponsored  Joint  Integrated  Avionics  Working  Group  (JIAWG) 
described  in  DOD’s  "Joint  Integrated  Avionics  Plan  for  New 
Aircraft",  dated  March  1989  (Ref.  4).  This  architecture  is  a 
derivative  of  the  “Pave  Pillar”  architecture  recently  pioneered 
by  the  Air  Force  Avionic  Laboratory  (Wnght  Laboratory). 
TTiese  design  standardization  iniuatives  are  based  on  tlie  use  of 
modular  avionics,  high  speed  fiber-opttc  data  buses,  common 
processors,  and  reconfigurable  systems  architectures 
employing  common  modules  to  support  many  avionic 
subsystem  functions.  These  common  modules  will  depend 
largely  upon  VHSIC  chips  and  wafer-scale  integration  (Figure 
7),  allowing  functions  which  were  previously  performed  in 
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STANDARD  ELECTRONIC  MODULE 
SIZE  COMPARISON 
rigur*  8 

black  boxes  sized  to  Air  Transpon  Rack  (ATR)  standards  to  be 
housed  in  relaQvely  small  Standard  Electronic  Module  -  Size  E 
(SEM-E)  packages  (Figure  8).  These  modules  ’vill  be  housed  in 
a  common  avionics  rack  (Figure  9),  and  will  communicate  via 
high-speed  (50  gigabits  per  second)  data  buses.  The  currently 
favoied  bus  design  is  the  Linear  Token  Passing  Bus  (LTPB), 
depicted  conceptually  in  Figure  10.  Such  a  net  wilt  permit  well 
disciplined  bus  management  (as  exemplified  by  MIl^STD- 
1533),  plus  token  passing  to  aid  lower  level  background 
communicadons  between  subsystems.  High  speed  data  buses 
will  also  be  employed  for  backplane  communications  between 
modules,  to  permit  rapid  access  to  extensively  shared  data.  The 
common  avionics  rack  will  be  liquid  cooled  to  ensure  a 
hospitable  operating  environment.  Several  modules  will  be  of 
common  design,  allowing  a  very  robust  design  wherein  system 
reconfiguration  may  be  accomplished  on  the  fly,  usuig  spate 
(or  idling)  modules  as  mission  lequiremenLs  or  equipment 
failures  dictate  (Figure  11). 


In  addition  to  the  advanced  capabilities  of  sensors  and 
processors,  and  redundancy  of  flight  and  mission  cntical 
functions,  special  attention  is  being  devoted  to  threat  and  target 
detection.  Sensor  correlation  in  systems  utilizing  two  or  more 
dissimilar  sensors  will  be  employed  to  achieve  better 
identification;  target  files  will  be  maintained  and  continuously 
updated;  target  prioritization  will  also  be  a  feature.  All  of  these 
functions  will  be  automated,  and  many  will  depend  upon 
"expert  systems”  and  neural  networks  (artificial  intelligence),  a 
feature  >vhich  is  frequently  viewed  by  me  operator  as  a 
“computer  in  the  back  seat"  (i.e.,  a  single-seated  fighter 
possessing  the  capabilities  of  a  two-seated  aircraft).  Such 
computer  systems  are  being  developed  through  the  “Pilot’s 
Associate”  program  by  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  (Ref.  5),  in  concert  with  the 
military  services.  Additional  research  is  being  pursued  by  the 
Air  Force  Avionics  Laboratory  and  industry  into  automatic 
target  recognition.  This  capability  will  be  based  upon  unique 
pattern  recognition  algonthms  and  the  synergistic  effects  of 
dissimilar  sensors  (i.e.,  “sensor  data  fusion”).  It  is  envisioned 
that  systems  usmg  this  technology  will  offer  a  capability  to 
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identify  and  pnontize  targets,  assigning  target  value  while 
assessing  nsk  of  engagement,  greatly  increasing  the 
effectiveness  of  our  weapons  systems. 

Vehicle  management  tasks  associated  with  internal 
weapons  system  operation  will  be  largely  automated,  and 
mission  management  aids  will  be  avaUable  to  support  in-flighl 
mission  changes,  perform  related  risk  assessments,  etc.  The 
pilot  will  be  able  to  tailor  the  performance  of  such  aids  during 
preflight  mission  preparations,  to  establish  extent  of  autonomy 
and  control  authority  to  be  delegated  to  the  system.  The  pilot 
will  retain  ultimate  control  authority,  but  he  may  confidently 
depend  upon  “the  computer"  to  assist  him  in  managing  his 
weapons  system  and  mission  functions . 

It  is  also  expected  that  future  systems  will  make  extensive 
use  of  integrated  diagnostics,  not  only  to  ease  the  maintenance 
burden  but  to  allow  in-flight  system  teconfigurauon.  Our  goal 
is  to  develop  a  next  generation  fighter  which  will  be  extremely 
reliable  and  self-sufficient,  capable  of  being  sent  on  routine 
deployments  for  up  to  30  days  without  dependence  upon 
addiuonal  support  staff  (maintenance  personnel,  ground 
support  equipment,  and  spares).  Such  weapons  systems  will  be 
expected  to  offer  greatly  improved  mission  reliabihty,  and  will 
also  enhance  safety  of  flight. 

In  addiuon  to  the  JIAWG  initiative,  the  Deputy  for 
Avionics  Control  (ASD/AFALC/AX)  is  developing  a  Modular 
Avionics  System  Architecture  (MASA)  design  approach 
(Ref.  6)  whic!i  closely  parallels  JIAWG.  It  is  quite  likely  that 
the  first  common  modules  derived  from  JIAWG  /  ATF  design 
activities  wll  form  the  initial  list  of  common  modules;  other 
modules  will  be  developed  and  added  to  the  MASA  list  as 
applications  evolve.  It  is  anticipated  that  the  MASA  approach 
will  be  applied  to  both  the  update  of  older,  existing  aircraft  in 
inventory,  as  well  as  future  aircraft  to  be  developed  throughout 
this  decade.  Similar  standardization  initiatives  are  being 
explored  by  industry,  through  several  groups: 

(1)  Aeronautical  Ra^o,  Inc  (ARINC),  by  their  Airlines 
Electronic  Engineering  Committee  (AEEC). 

(2)  The  Society  for  Automotive  Engineering  (SAE),  by 
their  Avionics  Systems  Division. 

(3)  NATO  Ah'  Standardization  Committee,  by  the 
Avionics  Systems  Working  Party. 

(4)  Air  Standardization  Coordinaung  Committee, 
Working  Party  50. 

The  SAE  has  drafted  a  number  of  preliminary  standards 
pertinent  to  various  aspects  of  modular  system  architecture, 
avionic  components,  and  high-speed  data  bus  designs.  Formal 


meetings  of  SAE’s  Avionics  Systems  Division  are  held  twice 
yearly,  to  r-view  stanis  and  propose,  updates  to  draft 
document!  tion  and  to  discuss  recent  industry  experience  and 
findings  relative  to  the  viability  of  proposed  design  guidance. 
The  military  services  have  also  participated  in  this  activity, 
thereby  insuring  a  balanced  perspective  of  evolving 
•  -quirements  (i.e.,  consideration  of  operational  requirements, 
operating  environment,  maintenance  support  structure,  etc.), 
liie  AEEC  meets  formally  on  an  annual  basis,  and  it  also  has 
produced  draft  design  guidance.  Whether  the  military  services 
will  use  any  of  these  specifications  and  standards  in  the  next 
generation  of  weapons  systems  remains  to  be  seen;  it  is 
believed  that  economic  forces  may  play  as  large  a  role  as  the 
technical  aspects,  and  _  , '  ?e  of  common  modules  in  both 
civil  and  military  aircrafi  applicati.  could  offer  significant 
financial  benefits.  Reliability  ot  performance  of  such  systems 
in  partirulsiiy  severe  military  operating  environments  will  be 
a  major  consideration.  The  NATO  and  ASCC  activities  meev 
independently  on  18-month  cycles,  and  are  beginning  to 
establish  similar  standards. 

Several  different  R&D  activities  within  our  AF 
laboratories  are  focusing  on  the  pilol/vehicle  interface.  We 
anticipate  that  the  aircrew  interface  requirements  will  become 
better  defined  and  validated  during  this  period,  particularly 
involving  cockpit  controls  and  displays.  In  the  near  term  we 
anticipate  increased  use  of  high  density  fiat  panel  display 
technology  (which  offers  lighter  and  mo.'^  reliable  displays, 
but  at  a  cost  of  increased  processing).  Hrlmet-mounted 
displays  are  also  emerging  which  offer  better  situabonal 
awareness  and  enhanced  air-to-air  tactical  engagement 
effectiveness.  Other  computer  intensive  capabilities  include 
in-flight  mission  planning  (which  will  allow  in-flight  mission 
changes,  location  of  moving  targets,  and  related  situation 
assessments/  mission  success  probability  estimations),  terrain 
mapping  data  (for  autonomous  navigation,  threat  vulnerability 
assessments,  terrain  following/  terrain  avoidance  flight,  and 
artificial  terrain  displays  for  use  at  night  or  in  adverse  weather 
conditions),  optimal  employment  of  active  and  passive  sensors 
and  countermeasures,  and  integrated  diagnostics  to  support 
avionic  system  reconfiguration  decisions  and  aircraft 
maintenance  activities. 

FUTURE  APPROACHES: 

The  manned  air  vehicle  remains  the  most  robust  means  for 
assunng  a  high  mission  success  rate.  Acting  as  the  "on  scene 
commander”,  the  pilot  is  in  the  most  advantageous  position  to 
observe,  measure,  and  evaluate  progress  toward 
accomplishment  of  mission  objectives.  He  will  be  capable  of 
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making  the  most  informed  decisions  regarding  continuation  or 
abort  of  missions.  The  future  challenges  are  many,  but  two 
stand  out: 

(1)  The  pilot  must  be  adequately  supported  m  the  arena 
of  information  management.  In  addition  to  threat  and 
target  detection,  identificatton,  and  prioritization,  we  must 
factor  in  all  available  information  (including  that  which 
may  be  available  from  external  agencies)  pertinent  to  the 
assigned  mission  We  must  present  this  infomiation  in  a 
manner  which  best  supports  the  pilot  in  his  role  as  a 
weapon  system  manager.  For  example,  if  the  pilot  wishes 
to  modify  his  flight  plan  to  pursue  an  alternate  mission, 
sufficient  resources  and  information  must  be  available  to 
support  thorough  evaluation  of  most  viable  options  ( and 
associated  risks).  Factors  which  must  be  considered 
include  level  of  exposure  to  threats  and  probability  of 
detection,  capabilities  of  on-board  counter-measures 
(including  state  of  expendables ),  weapon  system  health, 
and  required  coordination  with  other  mission  elements 
(including  formation  members). 

(2)  We  must  develop  weapons  systems  which  are 
reliable,  of  reasonable  cost,  and  which  possess  robust 
design  charactensdcs.  Such  designs  will  depend  in  large 
measure  upon  the  ability  to  share  resources  (for  example, 
common  processor  modules),  and  graceful  degradauon 
features  which  will  insure  a  tolerable  pdot  workload  and 
sufficiently  robust  system  capabilities  to  assure  compleuon 
of  assigned  missions  (or  capability  to  abort  and  safely 
return  to  base). 

(3)  We  must  carefully  examine  the  viability  of 
knowledge  based  “expert"  systems,  with  which  to  ease  the 
ptlot's  task.  Self-learning  (neural  net  based)  subsystem 
architectures  must  also  included  in  this  review. 

When  modular  avionics  system  designs  and  associated 
component  developments  come  to  fruition,  we  can  anttetpate 
that  the  core  avionic  system  components  will  be  widely 
available  and  in  numbers  which  will  perrmt  realization  of 
economy  of  scale.  Peculiar  system  designs  (for  mission 
peculiar  sensors  and  applications)  will  be  the  principal  drivers 
of  non-recuning  hardware  costs.  As  can  be  seen,  all  of  the 
requirements  Usted  in  the  preceding  paragraphs  are  software 
intensive;  one  may  readily  envision  that  the  principal  costs  of 
future  avionic  system  developments  will  be  associated  with 
the  development  of  software.  If  we  are  successful  in 
developing  a  good  library  of  computer  programs,  which  may 
become  standard  programs  (or  which  may  be  readily  modified 
as  necessary  for  mission  peculiar  applications),  the  expenses 
associated  with  software  development  may  also  begin  to  level 
off.  We  should  also  mention  the  need  for  high-density  mass 
memory  devices;  it  appears  that  the  laser  disk  memory  has 
great  potennal  to  support  idennfted  functtonal  requirements 
Considermg  the  evolving  sensor  technology  (electrontcally 
scanned  arrays,  etc.),  shared  antennas,  flat-panel  displays,  and 
common  avionic  modules,  we  believe  that  the  weight  of 
.  ‘ailed  avionics  (as  a  percentage  of  aircraft  empty  weight) 
has  leveled  off  and  will  remain  at  approximately  8  percent;  we 


do  not  foresee  significant  changes  m  this  decade.  System 
architectures  which  accommodate  large  amounts  of  parallel 
processing  are  assumed,  the  typical  OFF  may  contatn  2-to-4 
million  words!  Further,  integrated  diagnosbes  may  be 
expected  to  identify  and  locate  all  failures  to  the  module  or 
system  component  level  without  dependence  upon  ground 
support  equipment. 

CONCLUSIONS: 

The  modular  avionics  system  has  high  potennal  for 
controlling  the  escalating  costs  of  advanced  avionic  systems. 
With  its  basic  simplicity,  its  building  block  approach  and  task 
onented  functions,  we  believe  that  standardization  benefits 
and  economy  of  scale  of  this  approach  will  ultimately  force 
system  architectures  to  move  in  this  direction.  With  the  large 
amounts  of  parallel  processing  anticipated  m  future  systems, 
the  use  of  high-speed  inna-system  (fiber-optic)  networks  will 
become  the  norm.  In  addition  to  the  nansmission  of  sensor 
data  (and  attendant  time  correlation  requirements  in  the  data 
fusion  process),  common  access  to  large  amounts  of  stored 
data  will  place  additional  demands  on  high-speed  networks. 
Of  greatest  concern  will  be  the  development  of  mission 
peculiar  hardware  and  system  software.  With  proper 
management  attention  and  dedicated  effort  towards  builaing  a 
standardized  suite  of  core  modules  and  a  library  of 
standardized  computer  programs  and  software  development 
tools,  new  system  designs  may  be  efficiently  developed  and 
future  costs  of  avionics  may  be  readily  controlled. 
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1.  SIMIARY 

USAF  avionics  standardization  increased  83% 
in  applications  from  1980  to  1990. 

Docunented  cost  avoidance  of  $1.3  billion 
dollars  was  achieved  along  with  inproved 
operational  effectiveness.  For  continued 
success  in  avionics  standardization,  efforts 
cu:e  underway  to  identify  and  evaluate 
nethods  historically  used  to  assess  avionics 
applications  and  requiremsnts . 
Standardization  measures  and  lessons  learned 
from  past  efforts  are  also  being  evaluated. 
Infonmtion  obtained  will  serve  as  the  point 
of  depicirture  for  assessing  the  dynamic 
programnatic,  operationed,  and  technical 
forces  affecting  current  and  future  avionics 
system  architectures.  Results  will  help 
determine  future  standardization  and 
coinonality  initiatives .  Preliminary 
analysis  indicates  a  need  for  change  in  the 
selection  and  application  criteria  for 
standairdization  and  comonality  efforts. 

This  p)ap)er  reviews  avionics  standardization 
from  1980  to  1990.  Background,  definitions 
and  anticipated  benefits  of  avionics 
standairdization  are  presented  followed  by 
the  current  extent  of  standairds  application 
and  associated  cost  avoidainoe  summaries. 
Lessons  leaimed  from  the  past  10  yeairs  are 
highlighted  along  with  efforts  underway  to 
define  a  set  of  standauxiization  application 
and  inplenentation  criteria  designed  to 
identify  future  avionics  standairdization 
initiatives  and  quantify  anticipiated 
benefits . 

2.  BACKGRCUND 

Between  1975  and  1977  there  was  increasing 
concern  at  senior  policy  levels  over 
avionics  nenagement.  Examples  included: 
lack  of  a  bro^,  horizontal  (across  weapon 
systems)  picture;  inceasing  role  of 
avionics  due  to  technological  advances; 
proliferation  of  anriOTiics  (e.g.,  43  unique 
Inerticd  Navigation  Systems);  increasingly 
cotplex  logistics  support;  and  perceived 
unaffordable  solutions.  During  the  late  70s 
and  early  80s  the  Air  Force  established 
policy  to  ensure  cost  effective,  reliable 
avionics  mseting  required  mission 
requirements.  Attention  was  focused  on 
rational  use  of  standcirds  as  a  st’-ategy  to 
meet  this  objective.'  Use  was  based  upon 
programmatic,  technical,  and  cost  analysis 
versus  "for  standardization  sake",  hence  the 
term  "rational  standardization".  Trades  and 
analysis  were  to  be  done  early  in  the 
acquisition  process  in  order  to  make  the 
best  decision. 


Before  reviewing  Air  Force  success  using 
this  approach,  seme  definitions  are 
provided.  These  are  not  standard 
definitions,  but  will  be  used  for  this 
p>ap)er. 

Standard  Avionics  -  Avionics  which  confom 
to  specific  requirements  established  and 
documented  by  at  least  one  D^artment  oi 
Defense  (DOD)  organization. 

Cemmon  Avionics  -  Avionics  which  have 
multiple  ^plications  within  an  aircraft 
or  across  multiple  aircraft., 

Core  Avionics  -  Core  avionics  consist  of 
those  avionics  systems  that  are  typicoilly 
found  on  any  aircraft.  Examples  include 
radio/ccmnunication  systems,  navigation 
equipment  and  displays/instrumentation. 

Avionics  Standards  can  be  divided  into  two 
areas:,  hardware  standards  and  architectural 
standards . 

Avionics  Hardware  Standards  -  Avionics 
equipment  which  is  developed  or  adopted 
to  be  a  standard  to  fulfill  requirements 
for  a  functional  capability.  The  fiighest 
level  of  hardware  standardization  occurs 
at  the  line  replaceable  unit  (LRU)  level. 
These  LRUs  constitute  the  actual 
subsystems  (i.e.  "black  boxes") .  A  cemmon 
method  of  hardware  standardization 
involves  procuring  a  family  of  hardware 
standards  to  meet  severed  mission  needs 
verses  one.  Examples  include  the  Standard 
Central  Air  Data  Cenputer  (SCADC)  and  the 
Standeud  Flight  Data  Recorder  (STOR) . 
Examples  of  avionics  har^aure  standards 
are:  ARC-164  UHF  Radio,  ARC-186  VHF  Radio, 
ARN-118  TACAN  Set,  Standard  Central  Air 
Data  Computer,  Standard  Flight  Data 
Computer,  and  Standard  INU. 

Avionics  Architectiural  Standards  - 
Architectured  standaurds  generadly  govern 
how  avionics  equipment  and  subsystems 
interact  to  make  up  the  aircraft  avionics 
suite.  These  starriauds  deserroe  how 
avioni.cs  systems  communicate  with  each 
other  through  buses,  computer  instruction 
set  aurchitectures  or  ^gital  information 
from  higher  order  languages  (HOLs) 
instructions.  From  1980  to  1990  the  USAF 
architectural  standauds  in  use  include: 
HOLs,  MIL-STD  1815  Ada  and  MUr-STD  1589 
Jovial;  ISA,  MIL-STD  1750;  multiplex  data 
bus,  MIL-STD  1553;  and  the  aircraft /stores 
interface,  MIL-STD  1760. 


Avionics  Functional  Areas  -  Avionics 
functions  can  be  divided  into  the  areas  as 
shown  in  Table  1. 


C  COMMUNICATIONS 

CD  CONTROLS  AND  DISPLAYS 

EC  ELEOTROMAQNETIC  COMBAT 

FL  FLIGHT  CONTROLS 

ID  IDENTIFICATION 

N  NAVIGATION 

RE  RECONNAISSANCE 

SI  SYSTEM  INTEGRATION 

TA/S  TARGET  AOQUISITION/STRIKE 

Table  1  -  AVIONICS  FUNCTIONAL  AREAS 


Avionics  Nomenclature  -  For  designation 
purposes  avionics  hardware  items  are 
assigned  nomenclatures  through  the  Joint 
Electronics  Type  Designation  System. 
E-Yanples  include  ARC-164  UHF  radio,  ARN- 
118  TACAN,  AAU-34/A  Altimeter,  etc. 

Avionics  Installation  -  Indicates  quantity 
of  aircrauEt  a  specific  nomenclature  is 
installed  on  taking  into  account  quantity 
per  aircraft. 

Class  V  and  IV  Modifications  -  Typically 
Class  IV  modifications  r^resent 
reliability  and  maintainability  (R&M)  and 
safety  in^roveirents .  Class  V 
modifications  provide  capability 
increases . 


3.  EVOLUnCN  AND  APPUCATICN  CF  STANDARDS 

In  nany  cases,  the  Air  Force  has  elected  to 
adopt  a  successful  avionics  subsystem  as  a 
hardwaire  standard  for  subsequent 
application. These  were  and  still  are 
referred  to  as  defacto  standards.  In  other 
cases,  a  subsystem  was  developed  and 
acquired  as  a  standaud  item.  A  laurge 
percentage  of  these  ("developed  ais  a 
standaud")  replaced  older  systems  to  provide 
reliability  and  rraintadnabllity  (R&M) 
inprovements .  Architectural  standards  on 
the  other  hand,  resulted  from  pursuit  of 
laboratory  technology  developments.  Once  a 
standard  wais  develcpro  for  two  or  more 
applications,  the  system  engineering  process 
determined  whether  It  was  applied  to  other 
platforms.  For  both  haudware  and 
architectural  standauds,  each  program  office 
analyzes  various  avionics  alternatives,  each 
program  office  analyzed  various  avionics 
adtematives .  Based  rpon  cost,  schedule, 
performance  and  sxpportability  each  program 
director  selected  the  best  ^jproach. 
Typically,  if  an  avionics  standard 
alternative  was  picJced,  it  was  selected 
because  it  provided  the  required  capability 
at  the  lowest  LOC.  In  this  regard, 
assuming  functional  adequacy,  cost  was  the 


number  one  measurement  or  metric. 


4.  BENEFITS 

Several  avionics  standardization  ctojectives 
were  cited  in  a  1986  study*  conducted  for 
the  Deputy  for  Avionics  Control  (ASD- 
AID/AX) .  They  were  derived  through  review 
of  severed  past  avionics  standardization 
programs  and  interviews  with  personnel  from 
the  military  and  industrial  ccmrunity. 

These  objectives  were  identified  in  the 
study  as  criteria  by  which  the  avionics 
community  has  defined,  measured  and  judged 
the  success  of  avionics  standardization. 


V^IDE  APPLICABILITY 
COOT  AVOIDANCE 
RISK  REDUCTION 
EASE  OF  INTEGRATION 
TECHNOLOGY  MATURITY 

ADAPTABILITY  TO  CHANGING  REOUIREMENT8 
EASE  OF  TeCHNOLOGT  INSERTION 
ENHANCED  RELIABILITY  AND  SUPPORTABILITY 

Table  2  -  ANTICIPATED  BENEFITS 


"Benefits"  shown  in  Table  2  are 
interrelated,  but  are  not  nececsarily  listed 
in  ipriority  order.  For  example,  )dgh 
reliability  of  a  mature,  low  rls)c  standard 
contributes  to  the  cost  avoidance 
associated  with  using  that  standard  in  lieu 
of  a  less  reliable  item.  In  the  past,  the 
principal  tangible  benefit  was  cost 
avoidance.  Previous  LCC  aneilyses*  indicate 
a  15%  to  25%  cost  avoidance  with  use  of  a 
hardwaus  standard,  30%  for  ISA,  and  85%  for 
a  standard  bus.  These  percentages  were  not 
substantiated  nor  discounted  because  both 
unique  and  standard  cptions  were  not 
pursued;  however,  previous  government  and 
industry  studies  supported  these 
percentages .. 


5.  APPUCATICN  CF  AVICNICS  STANDARDS 

5.1  HARDWARE  STANDARDS  BY  AIRCRAFT  TYPE 

One  measure  of  staniterdization  progress  is 
the  cmantitative  change  in  arolication  of 
standarcds  (hardware  arid  architectural) . 
Using  data  frcm  the  Air  Force  Avionics 
Planning  Baseline  (APB)’  document,  the 
number  of  avionics  subsystems,  i.e., 
ncmenclatures,  were  totaled  for  1980  and 
1990.  This  was  a  unit  count  and  did  not 
consider  cost.  Percent  standairdization  was 
determined  based  on  the  number  of  hardware 
standards  ccmpared  to  Uie  LoLal  number  of 
ncmenclatures.  Data  indicated  that  in  1980 
11%  of  the  ncmenclatures  were  cxnsidered 
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Standard  (predctninately  in  the  area  of 
comunication,  e.g.,  2®C-164  UHF  radio)  and 
in  1990,  19%  of  the  syatems  were  standard. 
This  r^resents  an  83%  increase  in 
application  of  avionics  hardware  standards 
over  the  past  10  yecirs.  As  nentioned 
previously,  cost  was  not  a  consideration  so 
a  $1,0000,000  radar  was  equal  to  a  $10,000 
radio  for  this  single  paraneter  accounting. 


Flsure  1 


Figure  1  shows  this  increase  by  aircraft 
type.  Sons  obvious  results  are  highlighted. 
Baiters  and  cargo/tanker  aircraft  showed  the 
largest  increase.  Although  fighter  aircraft 
had  the  smallest  increase,  this  does  not 
inply  a  significant  difference  in  overall 
totals. 


Flgura  3 


Figure  3  shews  the  increase  in  avionics 
ncnenclatures  over  the  iMt  10  years.  Ihis 
represents  the  increeise  in  total  nuitber  of 
avionics  ncmsnclatures  (total  suite)  and  not 
the  toted,  change,  i.e.  all  Class  IV  and  V 
modifications ., 

Figure  4  shews  the  percentage  of  Class  IV 
and  Class  V  modifications  cenpleted  based  on 
the  nuntoer  of  ncnenclatured  items  in  1980. 

As  this  figure  depicts,  typiced.ly  there  were 
more  capability  enhancements  than  RSM 
ixrprovetnents  on  high  performance  aircrarft, 
with  the  opposite  true  for  Ccurgo/tanker 
adreraft.  Figure  5  shows  toteils  for  Class 
IV  and  V  modifications  and  what  portion  of 
these  changes  were  addition  of  standards. 


Figure  2 


Figure  4 


Figure  2  indicates  fighters  started  with  a 
higher  nuitber  of  standards  in  1980  than 
other  aircTcift;  however,  their  increase  over 
the  next  ten  years  was  a  lower  percentage. 
Figure  2  shows  the  change  in  niitber  of 
noienclatured  items  and  the  change  in 
quantity  of  aircraift  installations.  For 
exaiiple,  on  barber  aircraft  in  1980,  the 
standari;  tiere  evenly  distributed,  i.e., 
both  5%;  however,  in  1980  the  caego/tanker 
aircrjift  which  hal  larger  quantities,  had 
more  standards  (9%  and  25%) . 


In  prior  years,  statements  indicated  that 
the  growth  of  avionics  standards  would  be  in 
the  core  avionics  ctrea,  i.e., 
connunications,  navimtion,  and  controls  and 
displays  (including  Instruments) .  Rationale 
pointed  to  the  somewhat  universsil 
2pplicability,  core  avionics  subsystems 
offered.  It  wais  not  surprising,  tliat  after 
reviewing  APB  data,  this  sppears  to  hawe 
been  substantierted  from  1980  to  1990. 


'.'-.i'g"";' 
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STANDARD  AVIONICS  CHANGES 
«oeo  to  te90 

%  OF  1980  AVIONICS  SUITE 


figure  5 


For  each  of  the  avionica  functional  areas 
listed  previously,  Table  3  shows  the 
quantity  of  avionics  hardware  standards 
currently  in  the  inventory. 


PUNOTlONAL 

AACA 

QUANTITY* 

ACNCENT  OA 
TOTAl  STM  3aAM 

C 

4 

\2% 

CO 

14 

42% 

EC 

2 

e% 

FL 

1 

3% 

10 

1 

0% 

N 

0 

27% 

$1 

1 

d« 

TA/S 

t 

3% 

TOTAL 

C3 

ONt  Ptn  MMir  wtwM* 

r«W  a  -  AdONIOS  MAflOWne  STANOAHOS  fUWOnONAt.  AB€* 


AVIONICS  NOMENO-ATURES 

BY  FUNCTIONAL  AFEA 


%  OF  TOTAL  NOMFNCLATUREO  ITEMS 


Figure  6 

More  detailed  data  COToeming  the  nunber  of 
avionics  nansnclatures  and  correspOTiding 
nuntoer  of  installations  (aircraft  installs) 
by  functioned  area  was  tabulated.  The 
nurtber  of  nanenclatures  is  shown  in  Figure 
6.  Ihis  data  does  not  r^resent  the  nunber 
of  installations,  only  the  nunber  of  unique 


ncnenclatured  items,  i.e.  ARC-164,  ARC-190, 
ARN-118,  etc. 


AVIONICS  INSTALLATIONS 

BY  FUNCTIONAL  AREA 
»  OF  TOTAL  AVIONIOS  INSTALLATIONS 


Figure  7 

Figure  7  shows  how  these  items  were 
distributed  by  installation.  Ihe  data 
indicates  the  majority  of  avionics 
subsystems  were  controls  and  displays, 
navigation  and  ccnnunications  equrpment 
respectively.  As  a  percentage  of  actual 
installation,  the  controls  and  displays  area 
had  far  more  installations  than  any  other 
functional  area. 


AVIONICS  STANDARDS 

INSTALLATIONS  BY  FUNCTIONAL  AREAS 


FUNCTIONAL  AREAS 


Figure  9 


Figure  8  shows  the  nunber  of  standard 

installations,  of  vdiich  ccrnunications  had 

the  largest  nunber.  Again,  data  indicates 

that  ccrnunications,  navigation  and 

controls  and  displays  were  the  derdnate 

areas.  Also,  the  controls  and  displays 

area  had  a  very  high  instsdlation  count 

(Figure  7,  29%) ,  Icut  ccrpcured  to  the 

ccrnunications  area  had  a  low  percent  of 

standard  installations  (Figure  8,  15%) .  '> 
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5.3  ARCHITECTURAL  STANDARDS 

To  examine  the  use  of  architectural 
standards  two  msthods  were  used.  Ihe  first 
examined  the  use  of  three  standards 
(MIL-STD-1553,  Mrir-SlD-1750,  and 
MiIr-sro-1859)  across  the  fleet  by  aircraft 
type.  Data  weis  collected  on  the  nutiber  of 
aircraft  by  MissicmHDesign-Series  (fCS) 
which  used  MIIr-SlD-1553 .  Ihis  was  weighted 
by  the  quantity  of  MDS  2drcraft.  For 
exarrplef  if  an  aircraft  M3S  had  an 
application  of  MIIr-STD-1553  and  there  were 
200  of  these  aircraft,  this  r^resented  a 
count  of  200.-  Figure  9  provides  the 
results.  The  overall  usage  percentage  of 
MIIy-STD-1553  is  61%. 


edrcraft  (fighter,  bcnber,  and  cargo) .  Data 
was  collected  on  usage  of  four  architectural 
stcsidards.  For  MIIr-STD-1553  the  nurrber  of 
total  connecticxis  to  a  bus  was  determined 
and  a  percentage  taken  of  those  connected 
to  a  MIL-STD-1553  bus .  For  MIL-STD-1750  the 
total  nunter  of  16-bit  processors  was 
determined  and  a  percentage  taken  for  those 
that  were  MIL-STD-1750.-  Lines  of  code  which 
were  written  in  MIL-STD-1589  were  counted 
and  a  percentage  of  the  total  determined. 

For  MIL-STD-1760,  the  nuntjer  of  MIL-STD-1760 
connections  ccnpared  to  total  connections 
was  cilso  detentined.  Figure  10  provides  the 
results. 


ARCHITECTURAL  standards 

BY  A/noBAFT  TYPE 


»  Of  TOTAL  INVENTOPY  BY  AIBOPAFT  TYPE 


CDmii-ATOISM  tauL-tTOirM 


Flgura  9 

Figure  9  shows  that  high  performance 
aircraft  such  as  fighters,  have  e.xtensively 
used  MIL-STD-1553  cotpared  to  lower 
performance  aircraft  such  as  cargo/tanker. 
Ore  possible  reason  could  be  that  the  lower 
performance  aircraft  are  typically  older 
systems  and  they  pursue  fewer  major 
vpgrades.  The  majority  of  their 
iTDdifications  stem  frcm  RSM  inprovements. 


For  MIL-STD-1750,  the  same  type  of 
methodology  was  enployed.  That  is,  if  MIL- 
STD-1750  was  used  anywhere  on  an  aircraft 
WDS,  it  was  counted.  For  MIL-STD-1750  the 
data  was  not  readily  avEdlable  because 
records  did  not  consistently  indicate  MIL- 
STD  1750  uscige  for  enbedded  conputers. 

Figure  9  shews  the  results  reco^zing  that 
it  repreisents  a  conservartive  estimate  for 
the  nuntoer  of  applications,  i^fadn,  this 
standard  wais  used  more  extensively  on  the 
hio^ier  performance  aiircraft  with  the  sane 

rssible  rationade  ais  MtL-YSlD-1553 .  Figure 
also  shows  the  percent  of  adreraft  whidi 
had  at  least  one  atbedded  cerputer  using 
MIIf-STD-1589. 

The  above  methodology  does  not  provide  the 
extent  of  use  on  boaird  an  adrcraift.  The 
second  method  examined  three  types  of  rtodem 


ARCHITECTURAL  STANDARDS 

EXAMPLE)  WITHIN  WEAPON  SYSTEMS 


1863  IT60  ISSg  1T60  MAROWRE 

BUS  ISA  JOVIAL  INTERFACE 


ARCHITEOTURAL  8TANUAHD 
OPIDHTER  KaOARBO  ISSeOMBER 


Figure  10 

6.  AF  AViailCS  STRNDflBDIZftTICM  INVESTMENT 

Another  measure  of  stamdardization  progress 
is  the  cost  avoidamce  associated  with  using 
stauKiards.  Keoently  the  Deputy  for  Avionics 
Craitrol,  while  exanoning  the  gains  and 
payoffs  in  arvionics  stamdardizaticn  over  the 
last  10  years,  assessed  the  current  AF 
investment  in  avicxiics  stauxiauxiizatlon. 

Based  vpon  this,  the  c»st  avoidance 
associated  with  this  AF  investment  was 
detemdnijd.  A  gadn  wais  defined  as  the 
application  of  standards  and  a  payoff  was 
defined  a«  the  cost  avoidance  associated 
with  using  standauxis .  Totals  frcm  previous 
studies  indicated  a  ndniirum  cost  avo.idanoe 
of  $1.8  billion.  Results  frcm  these 
studies  were  used  as  justification  to  pursue 
develcpirent  or  use  of  a  standard  but  were 
not  ccnpletely  validated,  since  both 
alternatives  (standard  and  non-standard) 
were  not  pursiied.  Therefore,  there  was  a 
need  to  reassess  the  current  cost  avoidance 
in  order  to  use  it  as  a  netric  frcm  which 
future  assessments  could  be  measured. 

The  method  used  examined  life  cycle  costs 
associated  with  weapon  systems,  cTvicnics 
systems  and  standard  avionics.  By 
structuring  the  Epproach  in  this  manner, 
relationships  were  established  which  showed 
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the  portion  of  overadl  weapon  system  LOC 
cissociated  with  standaurds  and  also  the 
portion  of  avionics  LOC  associated  with 
standards.  In  order  to  ccnpare  resultant 
data  with  previous  studies,  a  15  year  LOC 
was  ccitputed  in  Fy89  dollars.  Ihe  LOC 
included  development,  production  and 
operations  and  sipport  costa. 

Preliitdnairy  efforts  concentrated  on 
representative  adrcraift  within  the  attack, 
fighter,  barter,  trainer,  cargo/transport, 
and  reconrraissaiice  type  aircraft.  IV»o 
fighter  aircraift  were  examined,  one  older 
version  and  one  newer  version,  this  data 
was  tlren  extrapolated  to  include  the  total 
aircraOEt  fleet.  For  these  aircraft  avionics 
LOG  and  standard  avionics  LOC  was 
extracted.  PCDS  were  not  considered.  Data 
sources  included  AF  cost  libraries,  AFLC 
data  systems  (OSS),  Government  and  Industry 
studies  and  the  ASD-AID/AX  data  base.  Data 
elements  are  sumrarized  in  Table  4. 


WEAPON  MT6M: 

AjnORAFr  TYPE 
OUAMTITV 

AmfPAME  OEVELOPUENI  COAT 
AlflOnAPr  OEVELOPWENT  oosr 
FLY/DWT  UHT  ooer 

16  YEAR  OPERATfONA  AND  AUPPORT  COAT 
MOHOE  AND  ATANOWO  AAONIOA: 

OUANtllV  PER  AIRCRAFT 
OCVEIOPUENT  COAT 
UNIT  COAT 

16  YEAR  OPERATIONS  AND  SUPPORT  OOST 


Ta1)(s  4  -  life  CraE  COST  WTA  elements  (16  YR  LCC) 


Oice  the  15  year  investment  associated  with 
standard  avionics  was  determined,  a  20% 
value  was  used  to  determine  the  cost 
avoidance  associated  with  the  use  of  these 
standEuds.  Ihe  20%  f.igure  was  validated 
based  rpon  the  average  reroentage  cost 
avoidance  previous  stLxJles  had  predicted  for 
use  of  standard  alternatives.  It  may  vary 
for  specific  uses  ;  however,  it  was  used  as 
a  baseline  at  this  level  of  aggregation. 

For  architectural  standards  extrapolation 
was  not  done.  Actuad  Investments  were 
determined  for  adl  applications.  Based  upcn 
previous  studies,  cost  avoidance  figures  of 
30%  for  an  ISA  aind  85%  for  a  data  bus  were 
used. 

Figure  11  provides  relative  estimates  fron  a 
weapon  system  perspective  of  the  percent  of 
avionics  LCC  and  standard  avionics  LOC 
associaited  with  each  weapons  .system  type. 

The  investment  in  standard  aivionics 
indicates  the  gains  made  in  avionics 
standardization  ard  can  serve  as  a  baseline 
for  future  assessments.  Also  shewn  is  the 
cost  avoidance  (payoff)  associaited  with  the 
use  of  standards  related  to  the  overall 
weapcxi  system  cost. 


As  seen  from  Figure  11,  avionics  investment 
is  higher  in  the  more  cotplex  aircraift 
(botfcer,  fighter,  recon)  which  was  due  to 
the  high  cost  of  mission  avionics.  For 
attack,  cargo  and  trainer  adreradt  the 
avionics  investment  is  a  smaller  peroentaige 
of  t)Te  overall  weapon  system  cost. 


Figur*  11 


Figure  12  shows  the  standard  avionics 
investment  auid  standard  avionics  cost 
avoidance  as  a  percentage  of  the  tot  ad 
aviofdcs  investment.  There  were  no 
siuprises  in  that  the  standard  avionics 
investment  indicates  a  higher  percentage  of 
the  avionics  investment  on  tlie  cargo  and 
trainer  type  aircraft,  than  the  rtore  ccnplex 
bentoer  and  fighter  type  aircraift..  This  was 
due  to  lower  avionics  unit  costs.  For 
exaiiple,  on  a  fighter  aiircraift,  the  million 
dollar  cost  of  the  radar  far  outweighed  a 
low  cost  instrument. 


Figure  12 


Figure  13  suimarizes  the  gains  and  payoffs 
for  the  last  10  years.  This  is  shown  from  a 
total  weapons  system  perspective  and  fron  an 
avionics  perspective. 
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WEAPON  SYSTEMS  AND  AVIONICS 
QAiNS  AND  FVVVOPFS 


WEAPON  8Y8TEM  LOG  A/I0NIC3  lOC 

CD  IONICS  LOG  K9  8TAN0AR03LCC 
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Figure  13 


toted)  were  done  by  the  Deputy  for  Avionics 
Caitrol  to  si?:port  the  evaluation  of 
standard  alternatives  when  there  was  an 
issue  or  a  user  request.  The  pivoted  output 
frem  these  assessments  was  the  relative 
delta  LOC  among  the  edtematives  ,i.e., 
TCrcent  increase  or  decrease.  However,  the 
$1.8  billion  tabulation  included  the  dollar 
delta  cited  in  these  acedyses.  These 
results  have  not  been  validated  as  mentioned 
earlier.-  The  $1.3  billion  cost  avoidance 
was  based  vpon  the  AF  standardization 
application  investment  which  represented 
actual  explications.  To  determine  the  cost 
avoidance,  the  20%  cost  avoidance  associated 
with  use  of  hardwaire  standards,  30%  for  use 
of  ISA,  and  85%  for  the  data  bus  figures 
were  used.  Work  now  needs  to  be  done  to 
substantiate  these  percentages  and  establish 
relationships  for  use  in  siJbsequent 
assessments . 


7.0  Lessons  Learned 

Over  the  last  ten  years  by  virtue  of  going 
through  the  processes  of  planning, 
developing  and  allying  standaumis,  there 
have  Iseen  several  key  points  vrtdch  lend 
themselves  to  be  categorized  as  "Lessons 
Learned".  These  fall  into  the  following 
au»as:  Metrics,  Timeliness  of  Standaurds, 
Cost  Avoidance  -  Contributing  Factors, 
Avionics  Standardization  Criteria,  and  Long 
Range  Itodification  Planning  verses  Short 
Term  Requirements . 

7,1  Metrics 

Pcist  estimates  for  the  Increase  in 
application  of  avionics  standards  indicated 
a  300%  increase  verses  the  83%  cited  in  this 
paper.  The  300%  and  the  83%  figure  were 
both  derived  from  APB  data;  however,  data 
reporting  was  not  consistent  between  1980 
and  1990  and  wais  not  au3counted  for  in  the 
300%  figure.  A  brief  explanation  is  needed. 
During  the  mdd  1980s  there  vreis  a  concerted 
effort  to  more  accurately  reflect  adl 
a-.'ionics  nomenclatures  on  each  aircradt. 

For  example,  considerable  work  was  done  in 
the  controls  and  displays  area,  v*dch 
included  instruments.  This  area  had,  as 
Table  3  indicates,  a  large  percentage  of 
standards.  Therefore,  the  reporting  of 
these  standards  was  accomplished;  however, 
in  most  caises  they  were  on  the  adoccraft  in 
1980,  hence  this  vas  not  a  read  increase. 
This  took  considerable  time  to  sort  out,  and 
required  ccntinual  interface  with  the 
personnel  responsible  for  data  collection. 
Solving  this  problem  for  future  assessments 
will  require  datta  base  refinements. 

Another  metric  used  to  exandne  avionics 
standardization  has  been  cost  atvoidance., 
iJere  agadn,  previous  reports  indicaited  a 
"conservative"  $1.8  billion  verses  the  $1.3 
billion  cited  in  this  paper.  The  $1.8 
billion  figure  wais  a  tabulation  of  results 
from  LCC  aissessments .  These  assessments  (16 


7.2  Timeliness  of  Standards 

A  constraining  factor  in  the  ability  to  have 
extensive  use  of  standards  is  the  timeliness 
of  those  standards.  MrL-?TI>-1553  is 
extensively  used  becauae  it  was  available  in 
the  703  during  periods  of  large  weapons 
systems  buys.  An  example  of  a  standard 
vmich  was  not  timely  was  DCD-STD-1788, 
Avionics  Interface  Desim  Standard.  DCD- 
STD-1788  was  conceived  in  1980  and  formally 
published  in  May  1985.  It  is  an  Interface 
DesiOT  Standard  that  specifies  the  black  box 
physicad  form  factor,  electrical  connector, 
aiJ^aft  racking  system  and  tray.s,  and 
s  ecific  maximum  heat  dls.sipation  'values  for 
the  various  size  blauxk  boxes.  In  vTune  of 
1986  frustration  was  expressed  over  attempts 
to  require  application  of  the  standard  to 
sever^  programe.  Based  upon  these 
concerns,  a  stuefy  was  done  by  the  Deputy  for 
Avionics  Control  to  validate  DCD-STD-1788 
as  a  viable  standiumi,  define  where  and  how 
it  should  be  used,  and  determine  its'  future 
as  new  stamxdards  evolve.  The  stuefy 
addressed  all  planned  aircraft  and  avionics 
development  and  mcxliflcatlon  programs.  It 
also  predicted  future  applications  due  to 
planned  changes,  capability  improvement  and 
introduction  of  new  aircaraft.  Cost  factors 
were  detenmined  concerning  the 
implementation  of  DCD-SID-1788  into 
airexadt.  These  cost  factors  were  then 
applied  to  a  fleet  wide  implementation.  The 
results  ot  the  study  shewed  that  the 
economic  benefits  of  DCI>-STD-1788  as  an 
interface  design  standard  did  not  araxeeu: 
significant  due  to  the  limited  application 
base.  DCD-SID-1788  did  offer  oUxm  benefits 
in  the  auea  of  reliability  and 
maintainability  (RsM) .  Howec’er,  these  were 
not  unique  to  IXD-STD-1788  since  other 
design  approaches  offered  the  same  benefits 
e.g.,  rear  connectors.  The  stuefy  concluded 
that  it  the  standard  could  have  been  applied 
in  the  70' s  as  was  MIL-STD-1553,  it  would 
have  nad  wide  application;,  however,  since 
it  was  a  black  box  conoe^  new  technology 
passed  it  by.  The  decision  was  to  not 
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require  its  use  on  new  edrcraft 
acquisitions.  Therefore,  tinellness  is  a 
key  factor  and  tecJinology  continually  needs 
to  be  assessed  and  proper  planning  done  so 
that  future  standards  have  a  viable  life 
span  such  as  MIIr-STD-1553. 


•7.3  Cost  Avoidanoe  -  Contributing  Factors 

Historically,  the  standardization  benefit 
associated  with  cost  avoidanoe  has  as  its 
nain  contributing  factor  reduction  of 
Operations  and  Seaport  (OfiS)  costs  . 
Topically,  this  was  attriouted  to  the  higher 
reliability  for  the  standard  alternative. 
Questions  as  to  why  the  steindard 
alternatives  had  higher  reliability  have  not 
been  thoroughly  investigated;  however,  it  is 
not  dependent  solely  on  the  fact  that  it  is 
a  standard.  Newer  technology,  proven  design 
and  acquisition  strategy  all  could 
contribute.  It  is  a  fact;  however,  that 
avionics  reliability  has  improved  and  as  it 
improved  the  cost  avoidanoe  contributions 
associated  with  reliability  improvements  is 
less  of  a  ccrntrlbuting  fjictor  to  the 
standard's  OSS  cost  inductions.  Efforts 
are  currently  underway  to  investigate 
factors  contributing  to  R6M  Improvements  to 
detennlne  relationships  between  RSM  and 
technology,  proven  design  and  acquisition 
strategy. 

7.4  Avionics  Standardization  Atplication 
and  Implementation  Criteria 

The  benefits  listed  previously  in  Table  2 
were  identified  as  criteria  which  the  Air 
Force  standardization  comnunity  selected 
initiatives.;  Topically  these  were  examined 
from  a  subsystem  point  of  view.-  It  is  clear 
that  ideiitification  of  standardization 
opportunities  in  future  decades  must  use  a 
broader  set  than  those  listed.  Not  only  is 
the  level  of  system  integration  increasing, 
but  the  acquisition  strategies  will 
emphasize  continuous  improvement,  total 
system  responsibility  and  integrated 
^plication  of  design,  engineering, 
manufacturing  and  logistics  disciplines. 
Further,  the  continued  introduction  of  new 
technolo^  must  be  accommodated  in  future 
acquisition  strategies. 

Table  5  provides  a  preliminary  list  of 
criteria  vdiich  attempts  to  capture  the 
essentied.  we^ion  system  verses  "strictly 
subsystem"  considerations.  These  will  help 
determine  the  level  of  expected  acceptance 
of  a  standaud.  After  assessments  using  this 
criteria  are  done,  IXXI  assessments  can  be 
daie  on  the  aLltetnatives  vrfiich  meet  or 
exceed  the  Table  5  criteria. 


A  brief  e:planatlon  of  each  criteria  element 
follows . 

STATED  BEQDIREEENT  -  Stated  Requirement 
refers  to  a  written  explicit  requirement 
from  a  weapon  system  perspective  to  akkl  a 


■  3WE0  BEQUIRFMENr 

-  INTEGRATED  PERFORMANCE 

-  installed  reliability 

-  OPERATIONAL  COMPATIBILITY 

-  MAINTENANCE  COMPATIBILITY 

-  'NSTALLATION/ENVIflONMENT 

-  SCHEDULE  COMPATIBILITY 

-  TIMELINESS 


T«bl8  S  -  standardization  CRITERIA 


capability  or  improve  supportability. 

INTEGRATED  PEBFCRtffiNCE  -  The  integrated 
performance  of  as  item  is  determined  by 
considering  clLI  function  required  of  the 
item  by  the  avionics  suite  and  the  system 
design  constraints.;  Consequently,  the 
iritegrated  performance  rerd.red  of  an 
item  may  be  more  complex  Uran  that 
provided  by  the  item  specification.- 

INSTALTfD  RELIABIUTY  -  Installed 
reliability  i.s  a  derived  we^xxr  system 
requirement  aillocated  down  to  the 
functional  level.  The  requirement  is 
based  upon  the  system  environment, 
mission  completion  criticality,  and 
integration  constradnts ., 

OPERATICNAL  CCM>ATIBIL1TI  -  This  is 
defined  ais  the  ability  of  the  standard  to 
operate  within  the  framework  of  the 
weapon  system  operational  requirements. 
For  ex&fiple,  weepon  system  operational 
requirements  such  as  stealth  may  dictate 
an  operational  mode(s)  not  typically 
associated  with  the  stanitord  or  unique  to 
one  application. 

MAINTENANCE  CCMPATTBILIIY  -  This  refers 
to  the  current  or  expected  method  of 
sxpporting  the  weapon  system.  The 
candidate  standard  must  have  a  support 
concept  that  is  consistent  and  compatible 
with  the  weapon  system  spproach. 

INSTALLAnCN/ENVIRClfCNT  -  This  is 
defined  as  the  impact  of  the  weapons 
systeme'  ^ysical  design  ccxistreiints  vpon 
the  itemo'  deslm  eind  performance. 
ConsiderEitions  inclvide  space 
availability,  weight,  power  availability, 
cooling  cspibility,  signed  interface, 
external  surface/ajpeture  constradnts  and 
vibrations . 

SCHEDULE  OCMPATIBILITy  -  This  refers  to 
the  schedule  requirements  for  the  various 
weapxMi  system  applications. 


Referencjes 


nMJLINESS  -  This  refers  to  assesaients 
of  current  and  future  technologies  which 
may  have  an  ijfipact  on  the  lifespan  of  the 
standard. 

7.4  Long  Range  Modification  Planning 

A  lar^  porticxi  of  the  modifications  for 
existing  aircrsift  are  done  on  a  single 
subsystem  basis .  Because  of  this 
opportunities  for  synergistic  benefits 
cissociated  with  long  range  modification 
planning  are  lost.  This  problem  is 
associated  with  the  process  in  that  it  does 
not  ccaisider  broad  or  long  range  planning 
i.e.,  considering  near  term  modifications 
for  on  single  weapon  systems  or  across 
weapon  systems.  For  exanple,  as  was  shown 
in  Figure  9,  MIL-STD-1553  was  not 
extensively  used  on  the  caurgo/tanker 
adrcraift.  The  high  payoff  associated  with 
use  of  MIIr-STD-1553  (85%)  was  mainly 
attributed  to  the  reduction  of  future 
integration  costs.  To  take  advantage  of 
this  amd  to  justify  its  first  application, 
long  term  modification  planning  should  be 
done. 


1.  "  Future  Standardization  Strategies", 
Prepared  by:  CNEIDA  RESOURCES,  DC,  2S 
January  1989. 

2.  ASD-AIJD/AX  Analysis  Reports:  "E-3 
Weather  Radau:  LCC",  i987;  "LOC  Anailysis 
of  Stamdaud  Architectural  Standards", 
1987;  "Standard  Flight  Data  Recorder 
LOC",  1988;  "Standard  Central  Air  Data 
Cenputer  LOC,  1985,  1989;  "Cenpass/AHRS 
LOC,  1988,1998;  "Modular  Avionics 
Handbook",  19  April  1990 

,3.  ASD-AIb/AX  Documents  and  Data  Base: 
"Avionics  Planning  Baiseline",  1980 
through  1990 


8.0  Conclusions 

As  stated  earlier  USAF  avionics  hardware 
standardization  Increased  83%  in 
applications  from  1980  to  1990.  This 
increase  was  concentrated  in  the  core 
avionics  auea  vMch  included  ccrmunications, 
navigation  and  iiwtnatentation.  The  barters 
and  cargo/tanker  aircraft  had  the  largest 
increase  for  hardware  standards  vhlle  the 
higher  performance  aircraft  showed  the 
largest  application  percentage  for 
architecturad  standartls.  Cost  avoidance 
suitmaries  indicted  .2%  of  Weapxn  System  LOC 
and/or  2%  of  the  Avionics  ICC  wcis  avoided  by 
use  of  hardware  and  auchitectured  standards. 
This  amount  varied  across  aircraft  type 
(hic^  performance  versed  lower  performance) 
because  of  the  different  mixes  of  avionics 
unit  costs  cerprising  the  total  weapon 
system  avionics  LCC.  The  cost  avoidance 
attributed  to  auchltectural  standards  was  a 
larger  peroentatge  on  the  higher  performance 
aircraft  than  cauw/tanker  type  adrerartt. 

For  the  fighter  aircratft  this  conprised  50% 
of  the  cost  awoidanoe.  This  is  due  to  the 
high  dynamic,  cetplex  nature  of  changes  on 
these  aircraift;  and  the  eawe  of  intecfration 
auxhitectural  standauds  offer.  In 
conclusion  it  appears  the  Air  Force  has 
shown  gains  and  payoffs  associated  with 
avionics  standardization.  The  challenge 
new,  is  now  to  '  .e  awivantage  of  the  high 
payoff  a3socia,.jd  with  use  of  aurchitectural 
standauxJs  for  add  aircreift  not  just  our  high 
performance  adrcraift. 
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Historical  Perspective  on  the  Evolution  of  Avionics  Standards 


Dr.  John  C.  Ruth 

Chief  Engineer,  Avionics  Technology 
Boeing  Military  Airplanes 
P.  0.  Box  3707,  M/S  4C-64 
Seattle,  WA  98124-2207 
U.S.A. 


This  p«p*r  will  pr«s«nt  th«  <l«v«lopm«nt  ot 
int«rfac«  st«nd«rds  fron  th«  l«te  1960's  to 
tho  ffliddlo  19d0's.  An  Avionics  Laboratory 
ma^or  pro^ran,  tha  Digital  Avionics 
Information  Systom(  DAIS)  played  a  key  role 
in  the  evolution  of  these  standards. 

The  DAIS  program  considered  interface 
standards  in  its  basic  concept  and  the 
cornerstones  of  the  DAIS  concept  wete* 

a.  A  digital  multiplex  distribution 
system. 

b.  Functional  software  coded  in  a 
Higher  Order  Language. 

c.  A  functional  interface  standard  for 
processors  in  theform  of  a  common 
instructional  set  architecture. 

d.  A  glass  coc)<pit  with  interactive 
displays . 

The  DAIS  hypothesis  was  that  significant 
ownership  savings  could  be  obtained  on  an 
aircraft  and  other  weapon  systems  if  some 
type  of  standard  interfaces  were 
established.  Commonality  of  hardware  was 
not  the  driving  issue,  but  standards  which 
defined  the  key  interfaces  and  did  not 
inhibit  creative  and  innovative  technology 
upgrades  was  imperative.  The  DAIS  program 
endorsed  many  of  the  standards,  1553,  1589, 
1750,  and  1760,  by  which  avionics  designers 
now  design  highly  integrated  systems. 

THE  DAIS  PROGRAM 

In  the  early  i970's,  the  designer  of 
military  avionics  systems  was  facing  a 
seemingly  impossible  task.  On  the  one 
hand,  t  ?  rapid  advances  in  electronics 
technology  were  placing  an  ever  increasing 
premium  on  growth,,  capability,  and 
flexibility  -  the  need  to  respond  to 
changing  threats  and  missions,  and  react  to 
operational  requirement  changes  in  a  very 
short  time;  on  the  other  hand,  cost 
pressures  from  increased  system  complexity, 
higher  maintenance  expense  and  general 
economic  inflation  were  forcing  the 
designer  to  address  the  total  cost  of 
ownership  of  avionics  systems.  There  was  a 
new  approach  to  solving  the  dilemma  facing 
the  avionicb  system  designer.  It  is  based 
on  recognition  of  the  importance  of 
information  systems  in  the  design  and 
development  of  integrated  avionics  systems. 
The  cost  of  the  avionics  could  be  amortized 
over  many  systems  on  the  aircraft  and  also 
between  various  aircraft.  This  approach 
does  not  advocate  commonality,,  but  common 
(alike)  elements  in  the  system  would  drive 
down  the  total  costs.  Unfortunately  there 


IS  a  down  side  to  the  common  equipment 
approach;  the  present  technology  tends  to 
be  frozen  in  the  system  addressed. 

The  DAIS  concept  proposed  that  the 
processing,  multiplex,  software  language, 
and  display  functions  be  common  and  serve 
all  the  subfunctions  on  an  integrated 
basis.  In  this  way  the  DAIS  concept,  would 
have  the  flexibility  to  adapt  to  a  spectrum 
of  multiplex,  processing,,  softw«re 
languages,  and  display  needs;,  yet  maintain 
common  interface  processing  architectures, 
display  concepts,  and  software  standards. 

Prior  to  the  DAIS  concept  the  conventional 
approach  for  designing  an  integrated  "black 
box”  system  configuration  was  to  divide  the 
total  system  configuration  into  a  number  of 
more  or  less  autonomous  subsystems  and  then 
to  design  equipment  black  boxes  to  meet  the 
performance  requirements  of  each  of  the 
separate  subsystems.  Each  subsystem 
normally  performs  most  of  its  functions 
within  Itself,  indulging  sensing, 
computation,,  logic,  control  and  display. 
Furthermore,  each  of  the  subsystems  has 
usually  been  developed  and  built  by 
separate  subcontractors.  A  certain  amount 
of  integration  and  interface  among  these 
separate  subsystems  is  normally  provided,, 
but  the  overall  total  system  design  has 
often  been  characterized  by 
compartmentalized  functions  and  equipment 
uniqueness;,  duplicate  functions  and 
equipment ,  nonstandardized  in put /out put 
signals  with  unnecessary  conversion  from 
one  form  to  another,  resulting  ir. 
subsystem/ system  inflexibility.  This 
impacts  the  entire  life  cycle  cost  of  an 
avionics  systems  -  viz.  -  aircraft 
installation  retrofit  costs,  numbers  and 
variety  of  spares  required,,  AGE  costs,,  and 
extensive  training  requirements. 

The  DAIS  design  approach  starts  with  a 
total  system  concept  which  is  functionally 
orianted  rather  than  hardware-oriented. 
Although  the  total  system  still  consists  of 
a  number  of  subsystems,  the  word 
”subsystem’’  will  be  used  in  a  different 
connotation.  It  will  be  thought  of  more  in 
terms  of  subfunctions  rather  than  hardware. 

For  example,  a  "navi-^eLion  subsystem"  in 
DAIS  does  not  refer  to  a  set  of  black  boxes 
which  are  identifiable  uniquely  and 
exclusively  to  the  navigation  function  but 
to  a  set  of  navigation  identifiable 
functions  which  are  performed  in  various 
places  throughout  the  system.  Note  the 
system  is  not  dedicated  exclusively  to 
doing  the  navigation  function  alone;  it  is 
also  used  to  perform  the  functions  of  many 
other  "subsystems". 


AIR  VEHICLE  AVIONICS  INTEGRATION 

Avionics  int«9r«tion,  which  is  d«fin«d  h«r« 
as  tha  cooparativa  uso  of  sharad 
infornation  amon^  avionic  subsystams ,,  first 
bacama  a  nacassity  whan  raquiranants  for 
missions  and  thair  associatad  avionic 
hardwara  could  no  longar  ba  mat  practically 
in  air  vahiclas  with  indapandant  and  salf- 
sufficiant  subsystams.  Elimination  of 
unnacassary  duplication  of  information 
sansing  and  display,  parformanca  gains,, 
reliability  gains,  cost  reduction,,  and  lack 
of  space  are  usually  given  as  the  ma^or 
reasons  for  integration.  Subsystams  ware 
forced  to  depend  on  each  other  for  basic 
information.  This  level  of  integration 
began  with  the  most  complex  subsystem 
because  it  had  the  most  capability,  as  well 
as  the  most  need  for  information  from  other 
subsystems.  As  digital  technology 
progressed,  the  central  subsystem  was 
expanded  to  incorporate  mission  processing 
(processing  not  specifically  associated 
with  a  subsystem  or  display)  However, 
problems  arose  early  in  the  centralization 
approach  because  subsystems  were  designed 
with  no  concern  for  interconnection  with 
other  subsystems.  Each  subsystem  had  been 
specialized,  and  the  interfaces  reflected 
this  specialization.  The  central  computer 
input-output  (I/O)  circuitry  was  designed 
to  perform  the  functions  of  ordering  this 
incoming  and  outgoing  data,  and  the 
computer  ^as  often  small  compared  to  the 
size  and  complexity  of  the  I/O.  Even  so,, 
the  central  computer  concept  and  its 
associated  integration  upgraded  the 
capability  of  the  mission  and  made  sensible 
use  of  the  shared  information  It  was  then 
reasoned  that  some  of  the  centralization 
problems  related  to  the  complexity  of  the 
I/O  could  be  solved  if  the  circuitry  could 
be  partitioned  and  distributed,,  alleviating 
the  central  units's  complexity. 


Multiplexing,  which  makes  information 
transfer  convenient  and  simplifies  I/O, 
offered  this  capability,  and  the  extended 
computer  I/O  philosophy  was  developed. 
Multiplexing  makes  information  exchange 
convenient  because  sensors  and  processors 
are  all  "on  the  bus”.  Multiplexing 
simplifies  I/O  because  the  information 
transfer  medium  is  reduced  to  a  single  wire 
pair.  This  extended  I/O  philosophy  was 
adopted  extensively  by  military  avionics 
integrators  with  the  development  and  use  of 
military  minicomputers  and  the  availability 
of  lower  cost  digital  components. 


These  avionics  integration  methods  began  ♦’O 
be  referred  to  as  multicomputer  systems. 
This  made  possible  the  distribution  of  the 
computation  and  permitted  several  computers 
to  replace  t)ie  mor«  powerful  central 
processor.  Application  of  this  concept  in 
various  forms  existed  on  several  aircraft 
(e.g  ,  B-l,  F-16,  F-16  and  Space  Shuttle). 
From  the  subsystem  equipment  point  of  view, 
these  approaches  to  integration  use  both 
integration  units  for  unmodified  subsystem 
interfaces  and  embedded  interfaces  The 
integration  approach  using  multiplexing  is 
implemented  by  defining  information 
transfer  formats  and  electrical  interface 
characteristics.  Therefore,  the  functional 
performance  is  accomplished  by  both 
hardware  and  software.  Most  of  the 
problems  associated  with  the  centralized 
I/O  have  been  eliminated  by  this  approach, 
while  others  have  surfaced  (e.g.,  software 
complexity,  synchronous  ©Deration,  multiple 
executive  control,,  data  communication  and 
I/O  circuitry) . 


But  with  all  this,  a  decided  impiovement 
over  previous  approaches  has  been  achieved 
Technology  improvements  in  computers  and 
digital  hardware  (i.e  ,  m  i  c  r  op  r  oc*»v  r  s  ) 
and  maturation  of  the  software  design 
ptocess  allow  further  extension  of  the 
xntegrarion  approach  by  a  more  distributed 
system  concept  consisting  of  both 
microcomputers  and  minicomputers 

The  newel  integration  approaches  will  use 
more  processors  and  buses  to  functionally 
partition  the  avionics  along  common 
military  ard  industry  organizational  lines 
(such  as  navigation,  stores  management, 
control  and  displays  and  communication). 

This  functional  partitioning  should  further 
ease  the  integration  problem  by  allowing 
design  of  the  functions  to  be  developed 
more  independently  of  each  other  prior  to 
completing  the  total  avionics  integration. 

multiplexing  ADVANTAGE 

The  data  bus  piovides  a  path  upon  which 
many  users  can  communicate  with  each  other 
without  requiring  a  dedicated  link  to  each 
other.  Weight  saving  is  achieved  by 
reduction  of  wire  weight  provided  by  the 
serial  multiplexing  of  digital  data  as 
compared  with  the  point-to-point 
undirectional  interconnection  required  to 
achieve  similar  integration  without  the 
data  bus.  Weight  savings  vary  greatly 
among  the  systems  being  compared  with  the 
data  bus.  If  an  analog  system  with  analog 
point-to-point  wiring  is  compared  with  a 
digital  multiplex  system,  considerable  wire 
weight  savings  can  be  achieved.  This 
weight  saving  will  be  reduced  so  what  if 
the  analog  sensors  and  displays  a,'j 
connected  with  integration  units  that 
interface  these  sensors  and  displays  with 
the  data  bus.  In  ocher  words,  the  overall 
weight  savings  resulting  from  the  reduction 
of  aircraft  witing  is  offset  by  the  weight 
of  integration  units  However,  if  the 
subsystem  is  digital  and  compatible  with 
the  bus  interface,  the  offset  is  recovered. 
Another  comparison  of  weight  sa'*ing  (but 
not  as  great  as  in  the  previous  case)  is  .1 
digital  systen  that  uses  digital  point-to- 
point  data  interconnections  with  a  approach 
to  integration,  the  advantage  is  in  the 
multiple  t  ccess  provided  by  the  data  bus  in 
contrast  with  the  point-to  point 
interconnects  previously  required. 
Therefore,,  smaller  gams  are  achieved 
because  both  systems  use  integration  and 
multiplexing  in  slightly  different  way^ 

Each  example  represents  extremes  in  weight 
savings.  Most  new  and  existing  systems 
will  exist  within  these  bounds  with  a 
mixture  of  both  types,,  thus  providing 
varying  weight  savings  dependent  on  the 
actual  use . 
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The  integration  flexibility  that  is 
available  is  one  of  the  key  features  of 
this  method  of  integration.  Because  of  the 
common  serial  interface,,  the  high  data  rate 
(up  to  50,000  words  per  second),  the 
multiple  access,  and  the  command/response 
data  format  provides  extensive  flexibility 
m  the  dcvclop.r.snt  period  as  well  as  during 
the  operational  time  period. 

Other  digital  integration  methods  have 
failed  to  meet  the  flexibility  requirements 
necessary  in  the  military  environment. 

These  failures  have  occurred  due  to  the 
following  reasons* 


a.  Too  low  a  data  rate  was  selected 

(data  rate  selected  based  on 


initial  ne«d  with  littla  growth 
capabi ] 1 ty ) . 

b.  Insufficient  definition  of 
interface  (difficulty  in 
duplicating  the  interface). 

c.  No  method  for  expansion  to  new 
sources  or  deletion  of  sources 
(inflexible  to  hardware  additions 
or  deletions ) . 

d.  Limited  data  encoding  and  decoding 
capability  (restricted  to  BCD  or 
ASCII ) . 

e  Limited  addressing  capability 

f.  Inefficient  data  transfer  (too  many 
wires,  too  much  overhead  pel  data 
wo  rd } 

g.  Difficult  to  simulate,  which  would 
provide  confidence  prior  to 
hardware  development . 

Each  deficiency  was  carefully  considered 
during  the  development  of  MIL-STD-1553 . 

The  detailed  electrical  interface  of  MIL- 
STD-^ISSB  provides  the  necessary 
requirements  information  to  allow  multiple 
'uppliers  to  build  compatible  interfaces. 
The  multiple  access  and  high  data  rate 
allow  extensive  integration  of  complex 
systems . 

The  capability  to  simulate  any  part  of  an 
integration  using  a  system  integration 
laboratory  prior  to  hardware  and  system 
design  commitment  reduces  the  risk  of  new 
developments  and  modifications.  The 
ability  to  communicate  data  in  a 
"transparent"  fashion  (i.e.,  the  mIL-STO* 
1553  system  manages  the  communication 
transfer  without  affecting  the  data)  is  an 
advantage  to  the  user.  T)ius,  the  data  user 
esn  encode  data  to  the  user’s  required 
format  and  not  to  the  transfer  system's 
format  Tho  use  of  message  addressing  per 
MIL-STD-1553  rathet  than  word  addressing 
allows  much  more  flexibility  than  can  be 
achieved  with  the  word  addressing  formats 
used  in  some  point-to-point  digital 
communication  approaches. 

A  final  advantage  of  this  approach  to 
information  transfer  is  the  ability  to 
control  data  flow  in  a  scheduled  manner 
from  one  location;  namely,  the  bus 
controller.  Changes  in  the  integration  can 
be  handled  by  message  changes  in  the  bus 
controller  rather  than  by  wiring  and 
hardware  changes  to  the  subsystems. 

APPLICATION  AREAS 

The  intended  application  of  tho  data  bus 
standard  includes  data  communication 
techniques  that  require  (1)  a 
command/response  format,,  (2)  a  time- 
division  multiplexed  data  transmission 
technique,  and  (3>  application  internal  to 
an  air  vehicle.  This  has  been  accomplished 
with  the  application  of  the  standard  to 
system  designs  that  accomplish  (1) 
integration  of  air  vehicle  functional 
groups  such  as  navigation,  weapon  delivery,, 
flight  control,  propulsion,  stores 
management,  defensive  systems, 
communications  and  control  and  displays  and 
(2)  integration  of  these  functional  groups 
into  a  weapons  system. 

The  application  of  these  system  designs  to 
various  vehicles  includes  fighters, 
bombers,  helicopters,,  and  transport 


aircraft  with  missions  of  attack, 
transport,  reconnaissance,  and  defense.  It 
has  therefore  been  demonstrated  that  the 
MIL-STD-15S3  approach  to  integration  has 
been  proved  applicable  to  a  wide  range  of 
air  vehicles,,  avionic  functions,  and 
missions  . 

MIL-STD-1553  Chronology 

The  society  of  Automotive  Engineers  (SAE),, 
Aerospace  Branch,  established  a 
subcommittee  of  industry  and  military 
personnel  in  1968  to  define  some  of  the 
basic  requirements  of  a  serial  data  bus. 

By  this  means,,  an  exchanga  of  industry  and 
military  views  was  accomplished.  The 
committee,  Multiplexing  for  Aircraft  (SAE- 
A2K},  developed  the  first  draft  of  a  data 
bus  standard  that  was  similar  to  tha 
present  military  standard  requirements  and 
procure  men*-  specification  raqui  remen  ts  . 

Its  format  allowed  standardisation  on 
requirements  that  could  ba  agraed  upon  and 
a  slash  sheet  in  the  appendix  for 
requirements  that  appeared  to  be  vehicle 
particular.  This  document  represented  the 
best  that  the  industry  and  the  military 
could  define  at  the  time.  The  benefit  of 
this  document  was  that  it  producad  a 
sounding  board  for  ideas.  In  this  respect,, 
It  was  successful  and  provided  the  step 
forward  required  to  develop  the  USAf 
military  standard,  MlL-STD-1 * 53 ,  in  August 
1973  . 

As  time  went  on,  the  original  aircraft 
avionic  suites  designed  around  MIL-STD-1553 
and  Its  forerunner,,  McDonnell  Douglas 
Aircraft  Company's  H009  ,,  made  use  of  the 
standard  interface  feature  of  the  data  bus. 
Avionic  upgrades  were  accomplished  by 
replacing  old  subsystems  with  new  ones 
designed  to  take  advantage  of  increased 
sensor  capabilities  and/or  to  insert  new 
technology.  The  black  boxes  were  switched 
with  minimum  systems  impact.  Ideally,  only 
the  software  in  the  bus  controller  was 
effected. 

During  the  years  frem  inception  of  the  SAE- 
A2K  to  the  release  of  the  first  military 
documents,  the  industry  was  designing  and 
producing  hardware  for  various  multiplex 
systems.  Some  of  these  systems  were 
developed  prior  to  or  during  the 
standardization  era  (e  g  ,,  r-15  and  B-1) 
Because  of  program  timing,  each  system  went 
Its  own  way  because  no  standardization 
effort  existed  at  the  time. 

From  1973  to  1975  (when  MlL-STD-1 553A  was 
released),  industry  and  the  military  (Air 
Force,  Army,  and  Navy)  coordinated  their 
efforts  to  determine  the  degree  of 
standardization  required.  During  this 
time,  several  preliminary  drafts  of  Air 
Force  and  Navy  documents  were  developed  and 
extensive  industry  comments  were  solicited. 
By  1975,,  the  DOD  directed  the  military  to 
develop  a  single  position  and  to  make  the 
necessary  revisions  to  MIL-STD-1553.  Based 
on  this  effort,  15S3A  was  released  in  April 
1975  and  its  first  incorporation  was  on  the 
F-16.  Since  then,  industry  and  the 
military  have  continued  tc  coordinate  the 
standard  through  symposia,  studies,  and 
military  development  programs.  With  the 
standard  available,  the  industry  and  the 
military  began  to  apply  the  data  bus  to 
more  operational  vehiclas  and  systems. 

As  applications  became  extensive,  certain 
difficulties  were  recognized  in  MIL-STD- 
I553A.  Discussions  concerning  these 
difficulties  were  conducted  between  the 
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SAB-A2K  «nd  th«  DOD  Tri-8«rvjic«s  Conimitc*« 
(th«  group  rasponsibl*  for  controlling  the 
military  standard).  Thasa  discussions 
resultad  in  the  formation  of  an  SA£  task 
group  { MIL-STD-1 553  Update)  in  October 

1976.  The  task  group's  assignment  was  to 
develop  suggested  changes  to  1553A.  Once 
again,  a  task  group  was  formed  from  several 
industry  and  military  segments. 

The  task  group  solicited  comments  from 
industry  and  the  military  to  support  its 
work  These  responses  were  extensive  and 
involved  foreign  as  well  as  domestic 
equipment  suppliers  and  users  of  the 
standard.  It  was  from  this  base  that  the 
task  group  developed  and  presented  the 
suggested  revisions  to  15S3A.  Zn  October 

1977,  after  review  and  discussion  of 
suggested  changes,  the  S.\E-A2K  approved  a 
proposed  revision;  in  December  1977  these 
recommendations  were  provided  to  the  DOD 
Tri-services  Committee.  In  addition  to  the 
SAE  input,  industry  comments  on  changes  to 
1553A  were  solicited  in  January  1978  by  the 
DOD  Tr  i*-s  e  r  VI  ces  Committee.  Based  on  these 
comments,  the  DOT  Tri-services  Committee 
met  on  several  occasions  and  produced  a 
draft  of  1S53B.  This  draft  was  presented 
to  the  SAE's  task  group  in  April  1978  for 
review  and  comment. 

As  avionics  systems  became  more 
buiJiU&tivated  and  more  highly  integrated, 
extra  protocol  features  such  as  mode  codes 
were  added  to  MI L-STD-1 S 53A ,  but  the  basic 
design,  operational  protocol  and 
physical/electrical  interfaces  were 
preserved.  No  further  changes  were 
permitted  and  the  standard  was  frozen  in 
th  4'  "B"  version  as  published  in  1978  and 
was  initially  incorporated  on  the  F-18. 

MIL-STD-15S38  contains  many  features,  all 
defined  in  detail,,  however,  not  all  need  to 
be  implemented  in  each  systems  application. 
The  standard  can  and  should  be  tailored. 

In  fact,  as  written,  it  forces  the  user  to 
make  choices  when  several  options  are 
provided,,  some  of  which  are  mutually 
exclusive.  For  example,^  you  can  choose 
either  a  single  or  dual-redundant  bus 
architecture  but  not  both;,  or  you  must 
decide  if  you  want  to  use  either 
transformer  or  direct  coupling  of  a  stub  at 
the  main  bus  interconnection  Zn  other 
areas  you  can  opt  to  implement  or  not 
implement  certain  protocol  features.  An 
example  here  might  be  choosing  to  implement 
the  "dynamic  bus  control"  mode  command 
which  allows  you  to  actively  hand-off  the 
master  bus  control  function  by  passing  it 
to  capable  (smait)  terminals;  and  not  to 
implement  the  "broadcast"  option  which 
permits  one  to  send  the  same  data 
simultaneously  to  all  terminals  and  thus 
suppressing  all  termini'  status  responses 
(handshakes)  which  art  .ornally  required  to 
confirm  receipt  of  transmitted  data.  In 
addition,,  each  system  that  applies  the 
standard  must  develop  a  tailored 
"application-oriented"  multiplex 
specification  defining  exactly  how  the  data 
bus  IS  going  to  be  used.  For  example  it 
would  define  such  things  ss  t.hc  numbwi  of 
terminals,  terminal  addresses,  installation 
routing,  design  stub  lengths  and 
connectors,  etc,.  Because  each  system 
designer  will  tailor  his  application  of  the 
standard,  the  remote  terminal  (RT) 
manufacturer  cannot  predict  the  exact 
options  that  will  be  actually  selected. 
Therefore,  most  RTs  are  designed  to  handle 
"all"  MIL-STD-1553  options  and  implements 
the  part  of  a  standard  that  is  not  a  design 
specification. 


As  more  and  more  systems  applications  fed 
back  their  "lessons  learned"  and  as  unique 
service  <U5AF,  USA  and  USN)  requirements 
developed,,  an  USAF  "Notice  1"  was  issued 
selecting  preferred  options  in 
architectural  features  and  protocol. 
Minimizing  the  choices  did  not  hinder  the 
data  bus  operation  but  did  not  provide  a 
degree  of  forced  subsystem  incerface 
commonality  and,  therefore,  resulted  in 
improved  hardware  competibility  and  system 
interoperability  in  aircraft  avionics. 

Also,  because  the  acceptance  of  the  data 
bus  integration  technique  spread  to  other 
applications  such  as  ships  and  vehicle 
electronics,  the  original  military 
standard,,  which  was  primarily  designed  for 
aircraft  avionics  integration  use,  was 
sanitized  by  removing  any  avionic  and/or 
aircraft  unique  references.  Because  this 
action  removed  any  military  unique 
requirements  from  the  standaid,  a  Tri- 
Service  "Notice  2"  wai{  published  in  1986. 
The  notice  states  which  options  each 
service  wants  to  implement  and  any 
restrictions,  interpretations  and/or 
clarification  that  they  felt  needed  to  be 
defined  in  order  to  enhance  understanding 
of  the  standard  as  used  in  their  military 
weapon  systems . 

An  Anecdote 

The  following  is  a  narrative  from  irv 
Cangl ,  ASD  Engineering,  Wnght-Patterson 
AFB,  Ohio.  Irv  was  a  leading  proponent  for 
the  1553  standard,  but  his  personal 
observations  give  a  certain  flavor  to  the 
evolution  of  the  standard.  It  is 
interesting  to  see  how  events  snd  certain 
circumstances  with  execution  timing  can 
influence  the  definition  of  a  standard. 

"When  I  was  assigned  to  the  FX  (F-15)  SPO 
in  1968  which  at  that  tire  was  still  in 
competition  with  three  primes,  McDonnell, 
Rockwell,,  and  Fairchild  l  told  them  that  I 
had  this  idea  of  simplifying  the  converter 
problem  by  ma)(ing  each  subsystem  put  out  a 
digital  link.  It  was  considered  high  risk 
and  was  turned  down.  After  the  avionics 
design  was  completed  by  each  contractor', 
all  three  were  determined  to  be  o  >rweight. 
With  a  commitment  ►o  a  total  gross  take-off 
weight  for  the  airctMft  a  weight  cutting 
exercise  in  every  dimension  still  left  them 
slightly  overweight.  Then  the  chief 
engineer  asked  me  "How  much  weight  might 
your  data  bus  save  on  the  rx?". 
Approximately  200  pounds,  I  said.  That  was 
^ust  what  we  needed  to  put  us  over  the 
hump.  So  1  was  asked  to  meet  with  all 
three  primes  and  initiate  a  feasibility 
demo.  This  was  done.  I  specified  to  them 
how  I  wanted  the  bus  to  function,  the  dual 
and  redundant  architecture  and  protocol.  i 
did  not  specify  the  medium  and  waveforms. 

Rockwell  had  Autonetics  build  a  coaxial 
frequency  division  bus  (like  the  747, 
entertainment  system).  It  did  not  work 
well.  Fairchild  was  teamed  with  Hughes  and 
demonstrated  a  system  that  worked  okey,  but 
was  rather  complex.  McDonnell  had  a  two 
wire  twisted  pair  (one  for  clock,  one  for 
data)  for  each  bus  and  successfully 
continued  to  operate  when  one  bus  was  cut 
with  wire  cutters.  Thus  the  H009  bus  waf 
born.  They  used  a  sine/cosine  summing 
technique  to  transmit  the  data.  At  1  Mhz 
the  twisted  pair  looked  like  a  transmission 
line  causing  aata  skewing  based  on  wire 
length  and  thickness  variation.  It 
required  precise  control  techniques  and  was 
not  the  best  concept. 


I  then  briefed  and  sold  the  B-l  SPO  on 
using  the  ous  for  electrical  power  control 
promising  them  8000  pounds  of  copper 
savings  It  became  the  EMUX  design  done  by 
Radiation,  Inc.  (Harris  Systems)  under 
subcontract  to  Rockwell.  They  worked  with 
us  to  come  up  with  the  new  techniques  now 
in  1553  to  use  l^.anchester  coding,  etc,,.  It 
then  was  directed  that  the  electrical 
characteristics  also  be  used  for  AiiUX  and 
CITS  on  the  B-1.  This  was  done  and  Harris 
developed  an  encoder/decoder  chip  to  be 
used  with  the  EMUX.  I  was  challenged  by  my 
Colonel  to  standardize  the  bus  when  I  told 
him  that  even  though  all  three  B-1  buses 
had  the  same  electrical  characteristics, 
t)iey  w««re  incompatible  and  thus  CITS,  tho 
centralized  integrated  test  system,  had  tc 
build  translator  boxes  between  the  various 
buses.  For  example  the  EMUX  had  a  word 
length  of  24  bits  while  AMUX  and  CITS  were 
16  bit,  like  the  F-15- 

Thus  came  the  start  of  trying  to 
standardize  the  Multiplex  Data  Bus:  This 
was  circa  1970.  In  struggling  to  establish 
a  committee  to  assist  in  the 
standardization  process,  1  organized  an  in- 
house  group  in  engineering  to  look  at  all 
aspects  of  the  data  buses  use  in  avionics, 
also  including  in  the  membership,  the 
personnel  from  RtM  and  EMI,  To  justify 
such  a  large  group  my  boss  made  me  write  a 
charter  and  insisted  on  the  keeping  of 
minutes.  The  charter  was  passed  on  up  the 
line  for  approval.  When  it  reached  the  ASD 
Commander,  Lt .  Gen.  dinmy  Stewart,  it  was 
sent  back  unsigned  with  the  following 
message:  I  cannot  endorse  something  I 

don't  understand.  This  seems  high  risk  to 
me  and  I'd  rather  wait  and  see  what  will 
happen  first.  Let  Oangl  do  whatever  he 
wants  to  If  he  succeeds,  we'll  take  the 
credit;  if  he  fails  we  don't  know  anything 
about  It. 

The  committee  didn't  understand  the  concept 
either  and,  rather  then  getting  help  from 
them,  It  turned  into  an  educational 
process.  Program  offices  that  were 
approached  responded  negatively  predicting 
poor  reliability  and  high  risk.  For 
example,,  they  could  not  believe  that  one 
could  replace  hundreds  of  point>-to-point 
wires  and  numerous  cables/connectors  with 
just  "one"  puny  little  wire  pair. 

This  instilled  in  me  the  need  of  extreme 
reliability,  Thus  the  numerous  checks  in 
the  bus  design  sending  each  bit  and  its 
complement  (Manchester  Code),  word  parity,, 
word  count,  time-outs,  automatic 
retransmission  if  anything  is  out  of  place/, 
shielding  of  the  cable,  dual  redundant 
buses.  Looking  for  help  1  turned  to  a 
committee  of  the  Society  of  Automotive 
Engineers  which  cas  working  on 
standardizing  a  submarine  communications 
bus.  The  SAL/A2K  subcommittee  was  holding 
a  meeting  a.  SCI  in  Huntsville  which  I 
attended. 

With  the  expert  help  of  industry  1  found 
out  that  there  were  many  ways  to  build  a 
serial  multiplexed  data  bus;  all  of  the 
designs  were  good,  meeting  perceived 
requirements,  but  different  enough  to  make 
standardization  difficult.  Each  company 
had  their  own  design  including  the  Navy  and 
the  commercial  airline  standa  iization 
committee  (ARINC/ASCC) .  And  ^o  did  1,  but 
no  one  wanted  to  give  up  the.*  own  design. 
So  for  months  we  were  at  a  stalemate; 
until,  a  meeting  of  the  A2K  committee  held 
in  Warminister,  PA,  hosted  by  the  Navy.  At 
the  meeting,  after  talks  that  were 


fruitless  again,  a  half  a  dozen  of  us  met 
late  that  night,  after  dinner,  in  the 
chairman's  hotel  room  at  the  George 
Washington  Hotel.  I  found  out  that  each 
industry  membei  was  com.misf  loned  to  stick 
by  his  company's  design  because  of  the 
fact.  If  he  agreed  to  accept  his 
competitors  design,  it  would  give  that 
company  the  competitive  edge  in  future 
business . 

Thus, I  told  theo  that,  since  the  Air  Force 
so  far  was  the  only  user  of  the  multiplex 
data  bus,  the  standard  would  use  the 
electrical  cha i ac t o r i s t i cs  from  the  B-1  and 
the  protocol  from  tho  F-15  To  my 
surprise,  that  made  everyone  happVr  since 
losing  to  the  Government  was  not  considered 
giving  in 

Before  publishing  the  standard,  it  was 
coordinated  with  the  remainder  of  the  Air 
Foice  divisions  and  laboratories  known  to 
have  an  interest  in  multiplexing 
Following  this,  it  was  sent  to  all 
interested  ino*-stry  personnel  for  comment 
A  tri-svrvice  meeting  was  called  ir.  an 
effor*’  to  get  DOD  approval.  No  agreement 
was  reached  at  this  time  because  tne  Navy 
was  in  the  process  of  defining  their  own 
multiplex  system.  While  the  ASD  committee 
was  actively  defining  itr  '•tandard,  the 
chairman  joined  the  Socie.y  of  Automotive 
Engineers  (SAE)  A2K  committee  on  aircraft 
multiplexing . 

SEA-A2K  membership  is  a  joint  DOD/Industry 
group  interested  in  reducing  the 
proliferation  of  avionic  multiplexing. 

Their  effort  entailed  the  development  of  a 
specification  for  a  general  EMUX. 

After  establishment  of  the  AF  standard,  the 
Avionics  Laboratory,  as  part  of  their  DAIS 
pc'joct,  decided  to  utilize  MlL-STD-1553  as 
tieir  multiplexing  design  standard.  As  a 
result,  the  Navy  gave  up  its  unique 
approach  to  multiplexing  in  favor  of  the 
command/response  concept  defined  in  the  Air 
Force  otandard.  The  Navy's  claim,,  a  valid 
one,,  was  the  MIL-STD-1553  did  not  go  far 
enough  in  defining  the  total  multiplex 
system.  Therefore,  MIL-STD-1553  has  been 
extended  to  include  the  definition  of  the 
bus  controller  and  the  remote  terminal  as 
well  as  adding  the  flexibility  of  subsystem 
interrupt  and  block  data  transfe*"  without 
destroying  the  standard's  definition  of  the 
bus  system" . 

Evolution  of  MIL-STD-1773  Fiber  Optics 

The  data  bus  philosophy  and  the  resultant 
standard  interfaces  are  technology 
independent.  However,  the  design  which 
iaplereents  this  concept  is  limited  by  the 
transmission  media,  the  transmit/receive 
electronics  and  the  encoding/decoding  logic 
chip  design  selected.  It  is  no  wonder 
that,  as  fiber  optic  transmission 
technology  matured  and  was  being  applied  in 
the  comnerciai  world,  an  effort  was 
initiated  by  the  military  to  loo)<  into  its 
use  as  an  avionics  data  bus  medium.  Fiber 
optics  has  several  advantages  over  twisted 
pair  cables  that  make  it  the  ideal 
transmission  link  for  the  future. 

First,  it  has  the  capability  for 
transmitting  digital  data  at  extremely  high 
speeds  (primary  limited  only  by  the  speed 
of  the  electronics  on  either  end). 

Secondly,  it  is  not  susceptible  to  electro¬ 
magnetic  interference  (EMI)  nor  does  it 
radiate  any  signals  which  provides  both 
electrical  design  and  information  content' 
which  is  Tempest  proof.  Finally,  it;^ 
ultioatw  ovetall  systems  cost  is  expected 
to  be  considerably  lower. 
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Th«  logic  behind  the  KIL-STD-ITTS  concept 
IS  as  follows.  A  single  optical  fiber  is 
used  as  the  transmission  medium.  The  bus 
ties  into  tne  subsystem  via  a  fiber  optic 
connector.  The  transmission  waveform  i?  a 
"Jight"  encoded  emulation  of  the  electrical 
.Manchester  XI.  Bi  Phase  L  rode  used  in  the 
MIL-STD-1 553  wire  system.  A  light-to- 
oiectrical  transceiver  is  developed  to 
convert  the  light  inpulsea  to  electiical 
wavoforms,  and  vice  versa  The  electrical 
side  IS  loentical  to  what  a  subsystem 
tecninal  would  see  if  a  MI L^STD'^l 553 
manchester- to -electrical  transceiver  wa> 
used.  Til*  address  and  logic  decoding 
electronics  is  identical  since  MIL-STD-17T3 
uses  the  identical  message  format  and 
communications  protocol.  The  system 
throughout  : s  kept  at  the  one  megahertz  bit 
rate,  and  except  for  the  transceiver  and 
finer  optic  c<^nnector,^  the  date,  bus  medium 
IS  transoarent  to  the  rubsystem  (i.e  ,  it 
does  not  know,  nor  cate,  if  it  is  hooked  to 
a  1553  or  system). 

Because  the  sane  large  scale  integrated 
{LSI)  logic  chips  used  in  MIL-STr)-l773  are 
used  in  KIL-STD-1553B,  the  cost  of 
conversion  to  fiber  is  significantly 
reduced 

Convetstly,  the  desjgn  of  the 
conmand/response  protocol  embedded  in  these 
LSI  chips  limit  the  speed  at  which  decoding 
and  communications  is  programmed,,  address 
decoding  and  other  message  overhead  will 
actually  reduca  data  bit  throughout  to  less 
than  that.  The  application  of  MtL‘$TD-l?73 
IS  a  logical  evolutionary  step  towards  the 
future  by  utilizing  optical  components  to 
gain  all  the  stated  fiber  optic  advantages 
(except  speed)  when  used  as  a  bus  medium. 

It  will  be  shown  later  how  this  is  a 
necessary  step  towards  an  orderly  evolution 
to  high  speed  busing  technology. 

NEXT  GCNCPATION  A  HIGH  SPEED  DATA  BUS 

A  committee  of  the  Society  of  Automotive 
Engineers  (SAC/AC-96)  had  been  working  on 
the  definition  and  concept  of  operation  of 
an  avionic  High  Speed  Data  Bus  (HSDB).  As 
a  result  of  their  efforts,  tv; 
architectures  with  two  transmission  mediums 
were  under  consideration.  These 
architectures  include  a  ring  and  linear  buf 
with  both  coax  and  fiber  optic  cabling 
mediums.  Note  that  a  unique  requirement  of 
HSDB  IS  that  there  is  no  centralized  bus 
controller.  This  criterion  requires  a  less 
deterministic  approach  in  that  an  address¬ 
ing  scheme  was  developed  th  t  allowed 
subsystems  to  vie  for  bus  utilization. 

When  multiple  subsystems  request  bus  access 
simultaneously,  collisions  occur  and 
arbitration  has  to  be  initiated.  Who  gets 
the  bus  is  based  on  priority  and  the 
arbitration  algorithm  used,^  ”who'8  on 
first'/" 

Another  HSDB  requirement  is  that,  when  new 
subsystems  are  added  to  the  bus  or  existing 
ones  fail,  the  protocol  must  be  designed  to 
accommodate  this  bus  configuration 
modification  and  continue  operating  without 

In  MIL-STD-1553  for  example,  it  is 
necessary  to  reprogram  the  bus  controller 
to  accommodate  the  added  subsystem;  but  the 
MIL-STD-1553  protocol  has  predefined 
reconfiguration  criteria  resident  in  the 
bus  controller  on  how  to  handle  failed 
subsystems  in  order  to  continue  degraded,, 
but  uninterrupted  bus  operation. 


In  embedded  avionics  computer  systems  that 
operate  real  time,  data  utilized  in  complex 
equations,  such  as  weapons  delivery 
algorithms,,  are  needed  from  various 
functional  subsystems  in  the  sarae  time 
window  to  provide  accurate  results  MIL- 
STD-1553  16  especially  suited  for  this  kind 
of  problem.  Even  though  the  data 
transmissions  do  not  .have  to  be  clock 
synchronized  (i.e.,  it  is  an  asynchronous 
data  bus),  the  message  traffic,  controlled 
by  the  bus  controller,  is  handled 
sefjuentially  in  repeatable  frames  that  arc* 
very  predictable.  The  bus  controller 
assures  that  the  data  needed  in  the 
equation  IS  sampled  in  real  time  from 
whatever  sensor  that  provides  the 
information  in  a  sequential,  deterministic, 
manner.  That  is,,  't  assures  that  the 
sequence  of  events  that  gathers  the  data 
for  the  a'  >rithm  are  done  in  the  same  time 
window.  D<<  %  collection  is  sync  (data 
user)  driven  keeping  unwanted  data  off  the 
bus  and  reducing  the  bus  duty  cycle. 

Central  control  also  assures  system  data 
flow  synchronization  and  supports 
testability  by  accurate  event 
repeatability . 

In  the  HSDB  design,  data  is  source- 
generated  and  transmitted  asynchronously  on 
the  bus.  When  the  subsystem  gets  access  to 
the  bus,  which  also  happens  in  an 
asynchronous  manner,  the  data  generated  by 
the  subsystem  is  broadcast.  T)iis  approach 
requires  that  receivers  of  information  must 
actively  sort  through  the  data  looking  for 
the  wanted,  ignoring  the  undesirable.  Not 
all  data  is  needed  at  all  times,,  but  the 
extra  sent  is  not  perceived  as  a  problem 
because  of  the  significantly  higher 
throughput  capability  of  the  HSDB. 

The  HSDB  architecture  eliminates  the  nee' 
for  a  bus  controller  and  allows  new 
subsystems  to  pust  be  added  to  the  network 
to  vie  for  their  own  bus  time.  It  is 
assumed  those  subsystems  needing  the  new 
one's  data  will  be  reprogrammed  to  pick  it 
off  the  bus. 

Because  bus  access  ts  not  centrally 
controlled,  arrival  of  data  is 
unpredictable  and,  also,  the  subsystem  bus 
access  sequence  is  not  necessarily 
repeatable.  Therefore,  the  data  gathered 
from  the  various  subsystems  is  not 
guaranteed  to  have  been  sampled  in  the 
"same"  real  time  window.  As  a  result,  each 
data  sample  needs  to  be  time-tagged  at  the 
source.  So  when  the  weapon  delivery 
algorithm  is  solved,  for  example,,  all  these 
data  samples  that  dwfina  a  fixed  point  in 
space  at  any  specific  instant  of  time  (such 
as  navigational  coordinates,  altitude  above 
target,  range,,  ground  speed,  wind, 
attitude,  etc,.)  must  be  adjusted  to  fall 
within  the  same  real  time  window.  This 
requirement  establishes  a  nead  for  keaping 
track  of  data  samples  so  that 
interpolations  or  trend  predictions  could 
be  done  on  these  input  signals  to  put  them 
into  the  proper  time  perspective.  The 
result  15  higher  subsystem  processor 
software  and  execution  time  overhead.  It 
is  anticipet-ed  that  i.f  a  very  small  number 
of  terminals  are  on  tha  bus  there  will  be 
no  timing  problem;  however,  if  even  one 
fourth  the  maximum  of  the  64  terminal 
architecture  were  to  be  used,  the  number  of 
collisions  would  dramatically  increase  and 
most  lilcely  cause  a  serious  time  skew. 

Due  to  technological  advances  in  recent 
years,  processing  speeds  have  increased 
manifold.  Also,  the  new  HSDB  will  run  at 


dAta  rate  speeds  over  50  Mhz  with  a  tnininun 
of  20  Khz  throughput.  A  lot  more 
information  can  be  transmitted  on  the  bus 
despite  the  increased  bus  arbitration 
overhead.  New  weapon  systems  are  in  the 
bus  design  stages  that  require  this  high 
speed  capability  now! 

The  protocol  roust  allow  for  fault-tolerant 
architecture,  data  integrity  and  self- 
diagnostics.  The  general  feeling  in  the 
acquisition  community  is  that  arriving 
quickly  at  a  reliable,  standardized 
protocol  IS  still  a  high  risk  while  tne 
fiber  optic  medium  implementation  is  an 
acceptable  risk.  That  is,  militarized 
fiber  optic  components  are  in  development, 
but  few  large-scale  integrated  HSOB 
decoding  logic  circuits  exist.  The  use  of 
Mir,-STD-1773  control  of  the  high  speed 
digital  link  for  data  transfer  in  avionics 
can,^  if  desired,  be  extended  to  additional 
wavelength  division  links  that  can  carry 
either  additional  digital  data  or  even 
analog/video  data.  The  amount  of 
parallelism  is  only  limited  by  transceiver 
technology . 

HISTORY  OF  HIL-./TO-1589 

In  the  late  60's  and  early  70's,,  expert 
programmers  would  program  in  assembly 
language  because  the  cost  of  memory  was  so 
expensive.  If  a  higher  ordered  language 
were  used,,  it  would  have  to  be  compiled  and 
since  the  compilers  were  inefficient  it 
would  require  more  memory  than  if 
programmed  in  an  assembly  language.  With 
the  phenomenal  lowering  of  memory  costs, 
ard  the  ability  to  produce  more  efficient 
compilers  and  support  tools,  higher  order 
languages  became  the  way  of  software 
programming.  The  development  of  a  standard 
programming  language  is  a  multi-year  effort 
involving  many  phases  of  activity  starting 
with  language  requirements  analysis, 
leading  to  language  definition,  production 
of  compilers  and  programming  utilities,,  and 
then  configuration  management  of  the 
support  softwaie  and  documentatio - .  After 
a  study  of  the  requirements  for  a  standard 
Air  Force  high  order  language,  the 
JOVIAL/J73  language  was  defined  by  MIL-STD- 
i589A  (later  superseded  by  MIL-STD-1589B) . 
Several  years  of  compiler  development  has 
resulted  in  JOVIAL/J73  compilers  hosted  on 
three  mainframe  computers  and  targeted  to 
several  embedded  architectures.  The 
compilers  were  developed  before  the  other 
utilities  that  now  exist. 

There  are  four  major  utilities  apart  from 
the  compilers.  These  are: 

a.  Interactive  Debugger  -  DEC-10 
hosted  symbolic  debug  package, 

b.  Code  Auditor  -  IBM  370  hosted 
utility  to  check  conformance  of 
JOVIAL/J73  source  code  to  coding 
standards ,, 

c.  Program  Support  Library  -  IBM  370 
hosted  configuration  management 
utility, 

d  JOVIAL  Automatic  Validation  £y5te.7. 

-  IBM  370  hosted  utility  to  assist 
in  automatic  testing  of  JOVZAL 
ob}ect  code. 

There  are  many  facets  to  the  development  of 
a  standard  programming  language.  Those  who 
were  involved  with  the  evolution  of 
JOVIAL/J73  had  discovered  the  complexity  of 
standardization.  Many  important  lessons 


were  learned  in  bringing  JOVIAL  to  a  usable 
state.  These  lessons  were  applicable  to 
the  development  of  other  languages,  such 
as ,,  Ada  . 

The  four  most  important  lessons  are  the 
following: 

a.  optimizing  compilers  for  embedded 
targets  are  complex  pieces  of 
software.  The  same  standards  that 
are  used  for  applicati.7n  coding 
should  also  be  applied  to  compilor 
implementation.  A  sufficient 
design,  coding  and  test  period, 
should  be  allowed  for  a  compilers 
development  rather  than  have  ic 
driven  by  the  schedule  of  the 
operational  programs . 

b.  A  changing  language  specification 
during  compiler  development  opens 
the  door  to  an  implementation 
disaster.  Xf  a  magor  language 
change  is  necessary,  be  prepared  to 
go  back  to  the  design  phase  of  the 
compiler's  implementation . 

c  A  compiler  for  an  embedded  target 

must  gener..te  very  efficient  object 
code.  Plan  for  this  fact  in  the 
compiler's  design  phase  rather  than 
try  CO  retrofit  optimizations  in 
later . 

d  A  commonly  available  implementation 

language  on  mainframes,  such  as, 
FORTRAN  (and  perhaps  later  Ada) 
significantly  decreases  the  cost  of 
compiler  rehosting 

APPLICATION  OF  MIL-STD-1S89B 

JOVIAL  J73  as  described  by  M1L-STD-1589B 
was  the  current  Air  Force  standard  higher 
order  language  for  embedded  computet 
applications  software.  JOVIAL  is  a  block 
structured,  strong  type  checking,  procedure 
oriented  language.  This  version  combines 
the  features  of  many  earlier  dialects  of 
the  language,,  e.g.;  J3,  J3B,  J4  and  J73/I. 
i^eneral  Dynamics  was  implementing  all  of 
its  flight  programs  on  the  F-16  C/D 
avionics  in  JOVIAL  J73.  These  OFPs  include 
the  Fire  Control  Computer,  the  Data 
Transfer  Unit,  the  Stores  Management  Set, 
the  Multi-function  Display  Set  and  the  Up 
Front  Control  processor.  An  integrated 
JOVIAL  J73  support  Software  system  (I5SS) 
consisting  of  three  separate  computer 
programs  (a  compiler,  assembler,  and 
linker)  operating  in  a  common  IBM  370  type 
host  environment  was  developed  to  support 
this  use  of  JOVIAL  J73 . 

The  host  environment  forms  the  major 
interface  between  the  programs  and  the 
user,  and  provides  the  means  for  running 
the  programs  and  supplying  inputs  and 
outputs  . 

General  features  of  the  JOVIAL  ISSS  are  as 
follows . 

a.  Portability.  Host  dependent 
portions  of  the  system  are  being 
minimized  and  Isolated  to  allow  the 
system  to  bo  rehosted  with  a 
minimum  of  effort. 

b.  Retargetability .  Target  dependent 
features  of  the  system  are 
parameterized  and  isolated  to 
better  facilitate  changes  in  the 
target  computer  or  to  totally 
retarget  the  system. 
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c.  Appropriateness.  Tre  ISSS  is  being 
specifically  designed  to  support 
the  perfcrniance  .equirements 
associated  with  real-time  avionics 
so  f  twa  re 

d.  Maintainability.  The  ISSS  will  be 
maintainable  in  source  form  by 
organizations  other  than  the 

de vel ope  r . 

General  Dynamics  had  worked  with  the  USAP 
to  extend  this  common  support  software 
package  to  encompass  all  F-IS  avionics, 
including  GFE;  multiple  users  results  in 
multiple  benefits.  Cooperative  application 
resulted  in  faster  maturing  of  the  support 
package  and  provided  a  single,  unified,, 
support  software  package  at  the  ALC. 

MIL-STD-1815,,  Ada 

Many  of  the  procedures  developed  by  the  Air 
Force  for  controlling  JOVIAL  can  be  applied 
directly  to  Ada.  The  type  of  tailoring 
needed  for  some  of  these  procedures  is  the 
topic  of  this  Section,  in  which  we  point 
out  some  of  the  more  obvious  considerations 
to  be  made  in  preparing  for  Ada. 

a.  IMPACT  OF  DOD~WIDE  LANGUAGE.  Since 
Ada  IS  a  OOD-wide  language, 
maintenance  of  the  Ada  language 
standaid  will  require  coordination 
among  the  Air  Force,  Army,  and  Navy 
through  the  ^da  Joint  Program 
Office  (AJPO).  This  will  result  in 
a  >engthy  process  unless  efforts 
are  made  to  establish  an  efficient 
screening  procedure  for  proposed 
changes.  In  effect,  the  Services 
would  propose  changes  based 
principally  on  criteria  of  language 
utility;  and  the  DOO  would  dispose 
of  or  approve  those  changes  based 
principally  on  criteria  of  language 
and  compiler  impact  and  the 
coordinated  satisfaction  of  the 
needs  of  all  the  Services.  The 
current  JOVIAL  language  control 
mechanism  could  serve  for  the  Air 
Force  with  adjustment  of  the 
criteria  for  analysis  and 
acceptance 

b.  GRADUAL  TRANSITION  TO  Ada.  One 
point  that  nearly  everyone  in  the 
standardization  community  agrees 
with  IS,,  "We  want  to  profit  from 
our  lessons  learned  in  JOVIAL  and 
not  make  the  same  mistakes  in  the 
Ada  effort."  With  that  point  in 
mind,  the  trend  we  observe  in  the 
Air  Foice  towards  making  the  Ada 
transition  a  gradual  one  is  readily 
understood.  This  transition 
occurred  in  four  carefully  planned 
phases  chat  we  might  descriptively 
title  JOVIAL,  JOVIAL/Ada, 
Ada/JOVIAL,,  and  Ada.  With  the 
benefit  of  proven  language  control 
procedures  on  which  to  base  the 
transition  and  a  flexible  number  of 
computer  resources  from  which  to 
draw  in  implementing  each  phase, 
the  Air  Force  would  enjoy  a  high 
piooability  ot  success  with  such  an 
approach . 

c.  Ada  VALIDATION  POLICY.  The  Ada 
JOINT  PROGRAM  OFFICE  (AJPO), 
Staffed  with  Air  Force,  Navy  and 
Army  personnel,  has  the 
responsibility  for  ensuring  the 
appropriate  validation  of  Ada 
compilers  throughout  OOD.  AJPO 


policy  requires  that  before  a 
compiler  can  use  the  name  Ada,  it 
must  be  fully  validated,  i.e., 
there  must  be  a  current  certificate 
of  validation  issued  for  the 
compiler  from  the  AJPO  They  may 
also  require  renewal  of  the 
validation  every  two  years.  AJPO 
presently  allows  use  of  the 
trademark  Ada  in  conjunction  with 
partial  implementations  if  a  caveat 
IS  included  in  all  associated 
advertisements  These  policies 
mean  that  frequent  retesting  of 
full  and  partial  implementations  of 
Aaa  may  be  required,  and  therefore 
configuration  management  of  the  Ada 
Compiler  Validation  Capability 
(ACVC;  test  suite  will  be  very 
important . 

A  final  consideration  is  that  with 
the  explosion  of  Ada 
implementations  on  microprocessors, 
there  is  an  attending  requirement 
for  the  ACVC  to  be  adapted  to  the 
microprocessor  environment  It  is 
unlikely  that  these  processors  will 
host  an  Ada  Programming  Support 
Environment.  This  entire  area 
presents  additional  new  challenges 
for  establishing  validation  and 
configuration  management  procedures 
and  tools. 

d.  SIZE  OF  Ada  USER  COMMUNITV.  The 
DOD  standardization  policy  for  Ada 
obviously  resulted  in  an  Ada  users 
community  that  exceeds  the  size  of 
the  JOVIAL  users  community  by 
several  orders  of  magnitude.  User 
services  is  already  a  big  job  and 
that  job  will  increase 
significantly  for  the  Ada  users 
community.  We  recommend  a  direct 
extension  of  current  JOVIAL  users 
services,  with  the  addition  a 
liaison  function  to  interact  with 
other  user  groups  that  may  exist 
There  is  the  JOVIAL/Ada  Users  Group 
transitioning  to  an  Ada/JOVIAL 
Users  Group,  ano  by  popular  demand 
they  have  estBb>  ’.shed  the  "Ada 
Corner"  in  the  JOVIAL  Newsletter. 

e.  RAPID  GROWTH  OF  Ada  EXPERIENCE 
BASE.  With  Ada  an  early  emphasis 
on  user  support  and  coordination  is 
anticipated  among  the  Services  to 
assimilate  and  dispense  a  common 
knowledge  base.  Then,  as  the  users 
emerge,  a  rapid  growth  of  the  Ada 
experience  base  and  a  high  demand 
for  compiler  validation  services  is 
expected.  This  means  early 
preparation  is  essential  to  become 
familiar  with  ACVC  and  to  refine 
JOVIAL  procedures  for  administering 
it  effectively. 

f.  Ada  AS  AN  ANSI  STANDARD.  DOD 
recognized  that  to  accomplish  its 
long  term  purpose,  it  must  expose 
Ada  to  public  review  and  obtain  a 
national  consensus.  Therefore,  DOO 
approached  th«  Ametican  National 
Standards  Institute  (ANSI)  about 
making  Ada  an  ANSI  standard,  of 
three  possible  avenues  for 
accomplishing  this,  DOO  chose  the 
canvas  approach.  The  canvas  has 
been  completed. 

As  a  sponsor  of  Ada  as  an  ANSI 
standard,  the  OOD  will  be  totally 
responsible  for  maintenance  of  the 
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standard  Latar,  DoD  intends  to 
make  Ada  an  intarnational  standard 
through  the  Intarnational  Standards 
Organization  (ISO).  Tha  dagraa  to 
which  tha  DOD.  ANSI  and  ISO 
standards  ara  tha  sana  will  ba 
affactad  by  tha  raviaw  process  of 
tha  respactiva  organizations. 

Onca  Ada  is  an  ANSI  standard.^  it 
must  comply  with  ANSI  rules,  which 
require  that  tha  standards  must 
either  be  revised,  raaffirnad  or 
dropped  within  a  five  year  period. 
This  means  any  changes  to  HIL-STD" 
1815  will  be  reviewed  by  the  ANSI 
technical  conmittae  before  approval 
IS  given  to  implanant  those  changes 
in  tha  ANSI  standard.  Furthermore., 
if  Ada  becomes  an  ISO  standard, 
another  level  of  review  is  required 
by  an  international  committee  to 
approve  changes  to  the  ISO 
standard.  Notice  of  plans  to 
revise  the  ISO  standard  must  be 
given  to  the  international 
community  at  least  a  year  ahead  of 
the  target  date  for  revision  of  the 
stands  rd . 

SUMMARY  OF  SOFTWARE  STANDARDS 

JOVIAL  was  to  be  the  interim  standard 
language  for  Air  Force  avionics  embedded 
computers  until  Ada  became  available. 
Language  control  is  the  assurance  of  the 
integrity.,  stability,  consistency  and 
usability  of  the  language.  The  four  major 
elements  of  language  control  are:  (1)  a 
well  defined  and  consistent  policy  for 
controlling  language  changes.  (2)  a 
mechanism  for  making  these  changes.  O)  a 
mechanism  for  checking  for  conformance  to 
the  language  specification  and  (4)  a 
centralized  knowledge  source.  The 
principal  control  tasks  ace  establishing 
and  maintaining  Language  Control  Facility 
(LCD  policy,  maintaining  the  language 
specification,  maintaining  the  validation, 
performing  validations,  and  providing  user 
and  Program  Office  support.  The  LCF  has 
developed  rigorous  descriptions  of 
procedures  for  these  tasks  using  SADT 
models.  These  models  promote  tight 
administration  of  the  control  function  and 
provide  an  organized  basis  for 
reconfiguring  the  language  control  function 
to  new  languages,,  such  as  Ada. 

There  are  several  readily  recognized 
characteristics  of  Ada  that  need  to  be 
considered  in  establishing  language  control 
for  it.  First.,  since  Ada  is  DOD-wide, 
maintenance  of  the  specification  will 
require  inter-Service  and  AJPO  coordination 
and  will  be  a  lengthy  process.  One 
approach  to  streamlining  this  task  was  to 
establish  both  a  component  level  and  a  DoD 
lev«l  of  LCF  analysis,  and,  in  effects  set 
up  a  w«ll  coordinated  double-screening 
process.  Second,  the  Air  Force  trend 
toward  transitioning  to  Ada  very  gradually 
suggests  we  should  build  the  Ada  control 
function  to  be  operated  in  parallel  with 
that  for  JOVIAL,  then  gradually  phase  out 
the  latter.  Third,  a  need  is  anticipated 
for  frequent  testing  and  retesting  of  Ada 
compilers  and  a  possible  need  for 
validating  partial  implementations 
including  those  on  microprocessors.  This 
makes  configuration  management  of  the  ACVC 
a  very  important  factor  in  successful  test 
administration,  and  it  poses  many  new 
challenges  for  language  control.  Fourth., 
the  large  size  of  the  Ada  user  community 
makes  user  support  a  big  job.,  and  liaison 


among  user  groups  will  be  necessary. 

Fifth,  a  rapid  growth  of  the  Ada  experience 
base  and  an  equally  rapid  transition  to  a 
high  demand  for  validation  services  is 
anticipated.  Finally,  with  Ada  as  a 
military  (DOD),  ANSI  and  ISO  standard, 
coordination  on  changes  to  the  language 
Will  be  espacially  important  and  will 
affect  control  activities  at  all  levels. 

APRLICATION  OF  MIL-STD-1 750A  INSTRUCTIONAL 
SET  ARCHITECTURE 

The  Air  Force  wanted  to  develop  a  MIL-STD- 
1750A  chip  set.  However,  past  DoD 
contracting  for  "non-commercial"  chip  sets 
had  not  been  supported  by  the  semi¬ 
conductor  industry  becauso  of  the  low  (by 
then  standards)  quantity  production  runs 
planned.  To  interest  the  semi-conductor 
industry.,  ASD  decided  to  use  a  "prime 
airplane  contractor"  with  a  large 
production  run  to  incorporate  the  standard 
chip  set.  Thus,  the  r-16  System  Project 
office  contracted  with  General  Dynamics  to 
procure  a  small,  low-power,  cost  effective 
implementation  of  MI1-STD-1750A  for  use  on 
the  F-16  program. 

An  instruction  set  architecture  (ISA)  as 
described  in  MIL-STD-1750A  includes  not 
only  the  instruction  set,  but  also.,  the 
interrupts,  fault  handling  provisions, 
extended  memory  addressing,  and  protection 
mechanisms  as  viewed  by  the  machine 
language  programmer.  In  this  design,  all 
features  of  the  standard  are  partitioned 
into  three  sets  of  requirements:  (1)  the 
Central  Processing  Unit  (CPU)  incorporating 
all  mandatory  requirements  for  the  r-18; 

(2)  the  Memory  Mw«nagement  Unit  (MMU) 
combining  the  optional  features  of  extended 
memory  addressing  and  operating  system 
paging  protection;  and  (3)  the  Block 
Protect  Unit  (BPU)  holding  the  memory 
write-protection  maps.  Other  optional 
features  within  the  standard  are  left  to 
the  »mbedded  computer  system  designer  where 
they  may  be  incorporated  easily  with 
standard  digital  components. 

One  benefit  was  the  establishment  of  the 
MIL-STD-1750  Users  Croup  in  August  1979  as 
a  voluntary  organization  of  industry 
representative  to  exchange  information  and 
status  of  MIL-STD-1750,  and  to  recommend 
changes  to  the  standard.  This  established  a 
pattern  for  future  new  technology 
development.  MIL-5TD-1750  is  the  standard 
for  an  instruction  set  architecture.  It 
does  not  define  specific  implementation 
details  of  a  computer. 

The  benefits  of  this  standard  ISA  are  the 
use  and  re-use  of  available  support 
software  such  as  compilers  and  instruction 
level  simulators.  Other  benefits  achieved 
were:  (1)  reduction  in  total  support 

software  gained  by  the  use  of  the  standard 
ISA  for  two  or  more  computers  in  a  weapon 
system,  and  (2)  software  development 
independent  of  hardware  development. 

The  Air  Force  recognizes  the  group  as  the 
sole  industry  body  to  recommend  chenges  and 
improvements  to  the  standard.  Although  the 
Air  Force  and  other  government 
representatives  participate  in  the 
committee  and  group  discussion,  they  do  not 
vote.  The  Air  Force  uses  a  "Control  Board" 
to  accept  changes  or  refer  them  back  to  ths 
users  group.  The  control  board  and  the 
users  group  is  part  of  tne  control 
structure  which  the  Air  Force  has 
established  for  MIL-STD-1750. 
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The  committees  are  the  backbone  of  the 
group.  The  following  is  a  summary  of  the 
function  of  the  committees. 

Stands rds  -  To  interpret  and  clarify 
definitions  and  descriptions  appearing  in 
MI L-STD* 1 750 ;  to  assess  the  scope  and 
applicability  of  the  standard. 

Architecture  -  To  assess  the  value  and 
impact  of  proposed  architecture 
modifications  or  extensions  to  the 
standa  rd . 

Verification  -  To  address  issues  related  to 
verifying  and  certifying  MIL-STD-1750 
hardware  implementation. 

Software  Tools  -  To  act  as  an  information 
exchange  to  M1L*>STD‘-1750  related  software 
tools,  and  to  assess  the  need  for  MIL-STD- 
1750  support  tools. 

Liaison  -■  To  retain  communication  and 
coordination  with  other  related 
standardization  groups . 

The  group  has  meetings  three  or  four  times 
a  year,  each  for  about  two  days.  The 
committees  elect  their  own  committee 
officers  and  make  committee  reports  to  the 
full  Users  Group  at  each  meeting. 

THE  STORES  MANAGEMENT  INTERFACE  DEVELOPMENT 
-  MIL-STD-1760 

Interoperability  between  aircraft  and 
stores  was  precluded  by  a  set  of 
obstructions.  Within  this  set,  a  primary 
obstruction  was  the  nonstandard  aircraft- 
to-store  and  store-to-ai rcraft  electrical 
interface.  Interfaces  between  aircraft  and 
stores  are  becoming  increasingly 
sophisticated  and  complex.  At  the  same 
tine,^  theie  is  an  increasing  desire  on  the 
part  of  interoperability  between  aircraft 
and  stores. 

The  number  of  different  types  of  stores  is 
large  and  continues  to  grow  as  a  result  of 
development  and  acquisition  programs. 

Stores  include  conventional  general  purpose 
bombs,  guided  bomb  dispensers,  missiles 
(air-to-air  and  air-to-ground),  nuclear 
weapons,  sensor  pods,  dropped  sensors, 
camera  pods,  counter-  measure  pods,  fuel 
tanks,  dispensers,,  guns,  rockets,  etc. 
Interfaces  between  aircraft  and  stores  are 
only  partially  guided  by  standards  -and,, 
therefore,,  have  tended  to  evolve  into 
system  peculiar  mechanical 
adapters/connectors  ,  electronic  signals  ,, 
power  connections,  and  other  armament 
assemblies  which  make  interoperability 
impossible  without  major  modifications  to 
aircraft  and/or  stores  on  a  case-by-case 
basis.  The  trend  toward  more  complex  store 
functions  which  require  increasing  amounts 
of  avionics  data  from  aircraft  systems  is 
causing  the  problem  to  become  increasingly 
acute.  Examples  of  this  situation  are 
AMRAAM,  HARPOON,,  PHOENIX,,  HELLFIRC,,  ATLAS 
POD,,  ALCM,  etc,. 

On  the  aircraft  side  of  the  interface. 
Stores  Management  Systems  (SMS)  sr*  unique 
to  each  aircraft  type  and  sometimes  each 
model.  Old  aircraft  Stores  Management 
Systems  are  generally  hardwired,  not 
integrated  not  automated  and  reflect 
outmoded,,  obsolescent  electronics  design. 

Although  new  aircraft  SMS  designs  reflect 
current  technologies  in  electronics  • .d 
communications,  they  are  still  tailored  to 
a  specific  store  list  and  were  not  designed 


for  growth.  Invariably,  the  changing 
stores  list  requires  modifications  almost 
as  soon  as  the  aircraft  begins  its 
operational  life.  The  adoption  of 
acquisition  methods  which  result  in 
aircraft  systems  which  are  tailored  to 
handle  specified  lists  of  stores  has 
limited  weapon  system  capability,  growt-h, 
and  flexibility.  These  methods  yield 
weapon  systems  which  are  well  defined 
within  themselves,,  but  are  inflexible  and 
costly  to  modify. 

The  intent  behind  developing  MIL-STD-1760 
was  to  support  achievement  of 
interoperability  between  independently 
designed  stores  and  aircraft  by  imposing 
specific  interface  design  requirements 
applicable  to  each.  To  accomplish  thjs, 
the  interface  characteristics  of  the 
aircraft  and  of  the  stores  must  be 
controlled  so  that  each  unit  of  a  given 
kind,  e.g.,  a  carriage  store,  is 
functionally  interchangeable  with  any  other 
unit  of  the  same  kind. 

The  overall  goal  of  the  standard  is  to 
remove  non-standard  electrical  interface  as 
an  obstruction  to  interoperability 
Application  of  the  standard  will  result  in 
a  wide  range  of  stores  being  interoperable 
with  a  wide  range  of  aircraft. 

Modification  of  aircraft  and  store  hardware 
to  allow  individual  combinations  to  operate 
together  will  be  minimised.  The  use  of 
adapter  modules  will  be  discouraged  In 
this  way,,  the  effort  and  cost  necessary  to 
integrate  aircraft  and  stores  will  also  be 
minimized. 

MIL-STD-1760  was  designed  to  be  flexible 
enough  to  accommodate  individual  system 
peculiarities.  In  particular, 
implementation  may  change  with  technology 
advances  as  long  as  the  interface 
characteristics  are  maintained.  The  MIL- 
STD  addresses  only  the  electrical  interface 
between  aiicraft  and  stores. 

Compatibility  parameters  such  as  size,, 
weight,  aerodynamics,,  avionics 
capabilities,  etc.,  must  be  satisfied  in 
addition  to  the  electrical  interface  in 
order  to  realize  interoperability.  The 
electrical,  or  MIL-STD-1760,  portion  of  the 
aircraft/store  integration  effort  will 
ultimately  be  limited  to  developing 
software  modifications  necessary  to 
accommodate  new  stores. 

To  achieve  the  program  objectives,  the 
Aircraft/store  Electrical  Interconnection 
System  (HZL-STD-1760 )  consisted  of  three 
hierarchical  elements :  electrical , 
physical,  and  logical.  Each  elemant  is 
describad  below: 

a.  Electrical;  Tne  electrical  element 
quantitatively  specifies  the  signal 
set  the  aircraft  must  provide  and 
that  the  store  must  utilize.  The 
signal  set  for  the  Aircraft  Station 
Interface  was  published  in  July  of 
1961. 

b.  Physical:  The  physical  element  of 
the  standard  defines  the 
intermateability  characteristics  of 
a  set  of  armament  connectors.  It 
is  envisioned  that  the 
characteristics  of  the  following 
three  classes  of  connectors  will  be 
specified: 

o  An  umbilical  connect  for  gravity 
release  stores  employing  the  MIL- 
STD-1760  signal  set. 
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o  A  low  cost  connector  for  sinple 
stores  employing  e  limited  subset 
of  the  1760  signal  set. 

o  A  blind  mating  connector  foi  rail 
launched  stores  employing  the  1760 
signal  set. 

To  achieve  the  goal  of  interoperability,  it 
is  not  necessary  to  completely  describe  the 
interconnection  component  as  one  would,  for 
example,,  by  calling  out  a  particular  part 
number . 

The  physical  element  of  the  standard 
defines  only  those  characteristics 
essential  to  intermateabillty .  Essentially 
this  means  that  a  particular  set  of 
physical  dimensions  had  to  be  defined.  The 
method  of  achieving  this  definition  for 
gravity  release  and  most  e^ect  launch 
stores  was  to  select  a  set  from  an  existing 
state  of  the  art  connector.  Several 
manufacturers  designed  similar  connectors 
for  MIL'STD~1760  employment  under  the 
constraint  that  each  must  employ  the 
selected  set  of  intermateabillty 
dimensions.  The  problem  of 

intermateabillty  also  includes  defining  the 
connector  insert  physical  and  functional 
layouts,  particular  contacts,  crimping 
tools,  and  etc,.  In  all,  some  ten  or 
twelve  piece  part  specifications  were 
required  to  completely  define  a  connector 
as  a  functionally  intermateable  system. 

Most  of  these  have  been  developed, 
coordinated,  and  published  for  the  lanyard 
release  or  so  called  umbilical  connector 
for  gravity  release  weapon. 

The  umbilical  connector  described  above  is 
intended  for  relatively  sophisticated 
weapons  and  as  such  is  compl'^x.  There  was 
an  effort  under  the  SAE  AE*’9  Aerospace 
Avionics  Equipment  and  Integration 
committee  to  define  a  signal  set  for  simple 
low  cost  stores  (SLCS).  A  configuration 
employing  only  a  single  channel  KIL-STD- 
1553  data  link,  28  volt  dc  power,, 
addressing  lines,  and  associated  ground 
returns  has  been  proposed.  The  ma^^or 
difference  was  in  the  method  of  selecting 
the  intermateabillty  aspects. 

Rail-launched  weapons  pose  particular 
interconnection  problems  such  as  the 
necessity  for  blind  mating.  There  is  also 
the  problem  of  rocket  or  ^et  blast  burning 
of  connector  contacts#'  Because  of  these 
considerations  and  others,  the  definition 
of  the  physical  interface  for  rail-launched 
stores  was  deferred  to  following  that  for 
gravity  release  weapons.  The  first  store 
incorporating  the  NIL-STD-1760  interface  on 
the  F-16  will  be  the  AHRAAH  missile  which 
will  be  added  to  the  existing  A1M9 
stations . 

It  was  recognized  that  the  interface 
requirements  specified  for  the  AKRAAM 
program  were  going  to  impose  very  difficult 
and  complex  interconnection  problems. 

Since  the  AMRAAN  launcher  must  meet  certain 
interface  requirements  unique  to  each  of 
the  r-14,,  F-15,  F-16  and  r-18  aircraft, 
internal  space  allocation  for  the  connector 
and  Its  release  mechanism  was  critical. 

The  method  of  coupling  the  missile 
receptacle  to  the  launcher  connector  was  « 
readily  adaptable  to  other  rail-launched 
weapons.  That  possibility  in  itself  drove 
the  AMRAAM  connector  toward  a  standard 
device  # 

It  was  desirable  to  undergo  a  long  term 
systematic  development  program  for  these 


three  classes  of  connectors.  However,  the 
requirement  was  for  interoperability  was 
now.  The  approach  MIL-STD-1760  had  taken 
was  to  select  and  standardize  on  the  best 
which  is  available  or  can  be  made  available 
in  the  near  term. 

c#  Logical:  The  Logical  element  of 

MIL-STD-1760  is  primarily  concerned 
with  the  utilization  of  the  MZL- 
STD-1553  multiplex  data  bus. 
Although  this  multiplex  standard 
defines  word  types  and  protocols 
for  general  types*  of  data 
transfers,  further  definition  would 
be  helpful  to  optimally  apply  MIL- 
STD-1353  in  the  aircraft/store 
environment . 

It  was  envisioned  that  the  MJL-STD-1760 
logical  element  would  be  comprised  of  two 
primary  areas;  Standard  Data  Words  and 
Aircraft/store  Protocols.  Standard  Data 
Words  are  MIL-STD-1553  data  words  which 
have  been  assigned  specific  bit  patterns  to 
represent  functions,  commands  or  values. 

As  such,  they  provide  the  same  inrormetion 
to  all  users.  If  data  words  ere  not 
standardized,,  implementors  will  by 
necessity  derive  their  own.  Unique  words,, 
in  turn,  complicate  aircraft  or  store 
interpretive  hardware  and  software.  The 
Aircraft/Store  Protocol  area  provides  a 
definition  of  rules  to  transfer  data 
between  aircraft  and  stores.  Additional 
protocols  are  necessary  in  such  areas  as 
user  application  data,  store  addressing,, 
message  routing,  block  date  transfer, 
message  encoding,  encryption,,  and  fault 
handling. 

MZL-STD-1760  implements  a  new  philosophy  in 
aircraft/store  electrical  integration.  No 
longer  win  aircraft  be  restricted  to 
designs  for  unique  sets  of  store 
requirements  and,  conversely,  stores  will 
not  be  constreined  to  interfacing  with 
aircraft  peculiar  electrical 
configurations.  Through  NIL-STD-1760 , 
aircraft  will  offer  a  standard  electrical 
capability  and  stores  will  electrically 
integrate  in  a  prescribed  and  orderly 
manner.  Through  MIL-STD-1760 , 
interoperability  can  be  enhanced  and 
aircraft  modification  costs  reduced. 

ACCEPTANCE  OF  STANDARDIZATION 

The  success  of  any  standard  is  determined 
by  its  acceptance  in  the  community  at 
large.  it  is  not  enough  to  simply 
introduce  a  standard,  it  must  be  applied. 
The  degree  of  acceptance  is  often  affected 
by,  (1)  the  manner  in  which  the  standards 
are  developed  and  introduced  to  system 
designers,  and,,  (2)  how  they  impact 
organizational  structures.  To  improve  the 
speed  and  effectiveness  of  the 
standardization  process,  it  is  necessary  to 
choose  an  appropriate  acministrative 
approach  to  standardization. 

Four  ma^or  administrative  approaches  have 
been  used  to  introduce  standards.  These 
ere : 

a.  Defacto  industry  standard  -  an 
official  standard  is  adopted  by 
manufacturers  to  increase  product 
compatibility . 

b.  Technical  society  committee  ^  the 
standardization  process  officially 
sponsored  and  monitored  by  a 
recognized  technical  society,  such 
as  IEEE,,  SAE  or  EIA. 


C.  Us«r  Gtoup  >  A  COMliitt**  of 

interostod  nilitary  and  industry 
parsonnal  naats  ragularly  to 
davalop  or  matura  a  standard. 
Exanpias  ineluda  tha  JOVIAL  Usar's 
Group  and  tha  1750  Usar'a  Group. 

d.  Unilataral  govarnaant  -  an 

intarastad  govarnaant  organisation 
davalops  a  standard  and  raguiras 
its  usa  on  ralatad  prograas. 

Naithar  tha  defacto  industry  nor  tha 
unilataral  govarnnant  approach  hava  high 
succ^s^  ratas  sinca  only  ona  aida  of  tha 
product  davalopnant  partnership  is 
involved.  Both  tha  technical  sociaty 
ccmmittaa  and  user  group  approaches  hava 
vorkad  vary  wall.  For  systems  with  purely 
military  applications,  tha  user  group 
approach  is  favored  sinca  tha  military  can 
sponsor  tha  group.  Tha  military  can  than 
datarmina  tha  participants  in  tha  maating, 
sat  tha  frequency  of  tha  meetings,,  and  fix 
target  dates  for  tha  availability  of  draft 
standards . 

By  itself  standard  modular  executive 
software  provides  only  limited  improvements 
in  tha  system  software  design  and 
integration  effort.  Much  greater 
improvements  can  be  achieved  if  tha 
standard  modules  are  combined  with  standard 
interfaces  between  the  executive  to 
applications  and  application  tasks,  and  to 
the  buses.  A  rigid  executive  to  application 
interface,  such  as  the  one  developed  for 
the  DAIS  program,  permits  the  applications 
software  design  tasks  to  be  undertaken 
without  detailed  knowledge  of  either  the 
executive  or  the  system  control  procedures, 
in  addition,  the  applications  software  can 
be  functionally  partitioned  allowing 
independent  design  groups  to  define  and 
develop  portions  of  the  system.  As  long  as 
each  software  module  adheres  to  the 
standard  interface,  and  as  long  as  the 
standard  interface  module  includes  the  bus 
control  functions,  the  system  integration 
process  becomes  a  simple  mechanical  task. 

Technology  is  becoming  available  to 
significantly  increase  the  effectiveness  of 
military  aircraft  operating  at  night, 
weather  and  in  a  sevare  threat  environment. 
The  potentially  of  this  technology  can  be 
realized  through  improved  Integration 
design  based  upon  modular  hardware  end 
software  concepts  and  proper  application  of 
a  program  of  military  standards  acceptable 
to  industry. 

The  technical  approaches  selected  during 
these  efforts  need  to  be  rapidly  reflected 
in  additional  military  standards  that  will 
encourage  industry  wide  acceptance  of 
common  modular  desion  techniques. 


When  the  modularity  concept  is  fully 
exploited,  resultant  availability  and 
performanca  lavals  will  be  aquivalent  to  a 
larger  operating  fleet,  thus  providing 
force  multiplication,  current  Air  Force 
avionic  integration  technology  programs 
should  be  supported  to  provida  a  forum  and 
proving  ground  for  these  initiativas . 
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SUMMARY 


I  will  first  try  to  recall  the  different  bodies  which  deal  with  standardization  at  both  french  and 
european  levels. 

Avionics  standardization  in  Europe  relies  up  to  now  on  common  standards,  such  as  Stanags.  That 
approach  is  not  large  enough  to  ensure  real  interoperability,,  as  will  be  demonstrated  with  the  Link  1 6 
example. 


It  is  foreseen  that  one  of  the  major  challenges  for  future  avionics  standardization  will  be  the 
modularity.  For  some  reasons,  there  must  be  international  commonality  in  order  to  obtain  minimization  of 
costs. 


One  important  issue  is  clearly  the  applicability  of  modular  avionics  on  board  european  aircraft. 
This  has  been  studied  in  France  with  relation  to  the  Rafale.  The  results  of  that  study  will  be  discussed  in 
some  details. 

Another  issue  is  the  standardization  of  Instruction  Set  Architectures  (ISA)  in  the  field  of  data 
processing.  That  concept  helps  solving  some  problems,  such  as  software  interchangeability  and 
reconfigurability,  but  has  also  severe  drawbacks.  A  solution  to  the  need  which  does  not  Imply  common  ISAs 
is  envisaged  in  France  :  the  software  bus.  That  concept,  related  to  EXTRA  (for  Real  Time  Ada  Extension)  is 
proposed. 


It  Is  clearly  understood  in  Europe  that  modular  avionics  will  gam  maximum  advantage  if  its  F3I 
specifications  are  common  to  the  different  nations  and  services  within  NATO.  This  enforces  tlie  need  for 
cooperation  at  both  governemenlal  and  industrial  levels.  Europe  has  launched  two  multinational 
programmes  in  order  to  define  and  validate  a  common  avionics  architecture  for  application  in  the  2000's  : 
the  ASAAC  (cooperation  between  UK,  GE,  FR  and  hopefully  US)  and  the  EUCLID  CEPA  4  (within  the  lEPG) 
The  scope  and  content  of  first  phase  of  these  programmes  will  be  described. 


INTRODUCTION 


This  lecture  will  be  divided  into  five  main  parts  ; 

-  A  review  of  the  different  bodies  in  charge  of  aerospace  standardization  in  Europe. 

-  The  relationship  between  standardization  and  interoperability. 

-  An  example  of  area  where  standardization  has  large  implications  ;  modular  avionics. 
■  Another  example  •  the  Software  Bus. 

-  Conclusion. 


I  -  NORMALIZING  ORGANIZATIONS  IN  FRANCE  AND  IN  EUROPE 


The  organization  globally  in  charge  of  normalization  in  France  is  the  AFNOR  (Agence  Frangaise  de 
NORmalisation),  which  is  subordinate  to  the  Ministry  od  Industry.  It  elaborates  the  national  standards  (NF)  in 
every  industrial  sector,,  in  concert  with  other  specialized  normalization  offices. 

At  the  european  level,  the  counlerparl  of  the  AFNOR  is  the  CEN  (European  Standardization 
Committee),  which  works  out  the  European  Norms  (EN).  The  AFNOR  is  representing  France  within  the  CEN, 
while  other  national  organizations  represent  their  countries.  The  aerospace  industry  party  to  the  CEN  is  the 
AECMA,  which  gather  a  number  of  national  trade  associations. 

In  that  aerospace  sector,,  the  BNAE  (Bureau  de  Normalisation  de  I'A^ronaulique  et  de  I'Espace)  is  in 
charge  of  elaborating  and  editing  the  french  standards  (NFL).  For  that  purpose,  it  works  in  re'ation  with  the 
ministry  of  Defence,  via  the  DGA  (D6l6gation  66n6rale  pour  I'Armement),  and  with  industry,  via  the  GIFAS 
(Groupement  des  Industries  Frangaises  A6ronautiques  et  Spatiales,  the  french  ad  hoc  trade  association),  which 
secure  most  of  the  necessary  fundings. 

The  BNAE  may  also  assume  other  tasks,  such  as 

•  technical  support  to  the  elaboration  of  new  standards,  both  at  national  and  international  levels, 

-  conducting  inquiries  in  France  regarding  international  draft  standards. 

This  is  particularly  the  case  (or  NATO  standards  (Stanags)  in  avionics  (A VS  and  Al  NATO  groups). 
For  that  purpose,  it  has  set  up  several  specialized  working  groups,  to  which  the  Industry  and  the  DGA  take 
part. 

The  BNAE  IS  also  representing  France  at  ISO  (International  Standardization  Organization)  in  its 
area  (TC  20). 

Figure  1  describes  the  relationships  between  the  different  standardization  bodies  in  France,  in 
Europe,  within  NATO  and  worldwide.  Figure  2  shows  the  participating  countries  to  the  international  bodies. 


II  ■  STANDARDIZATION  AND  INTEROPERABILITY 


It  is  generally  agreed  that  interoperability  necessitates  the  conformance  to  common  standards.  The 
pending  question  is  ;  is  that  sufficient?  In  order  to  answer  it,  it  is  usefull  to  consider  a  particular  example  . 
the  link  16. 

Briefly  described,  the  link  16  is  a  protected,  networked  data  link,  that  is  defined  by  the  Stanag  n° 
5516,  which  amongst  others,  describes  the  usable  messages,  part  of  which  are  mandatory  and  other  are  not. 
The  organization  of  the  networking  and  of  the  messages  is  to  be  in  accordance  with  another  NATO  document,  the 
AdatP16. 

In  this  case,  interoperability  lies  In  the  ability  to  exchange  and  understand  messages  among 
different  participants  ;  Air,  Land  and  Sea  Forces  from  one  or  several  allied  contries.  This  means  that  the 
following  must  be  defined  : 

-  the  multi-forces  or  multi-national  networks  that  will  allow  the  exchange  of  information, 

-  the  messages  that  will  be  exchanged  within  each  network,  together  with  their  emission  order  and 
time  by  the  terminals, 

-  the  content,  formatted  at  the  bit  level,  of  the  messages  (field). 

For  each  net,  it  is  necessary  to  define  data  transmission  frames  in  the  same  way  it  has  to  be  done 
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for  such  a  multipexed  bus  as  1553B.  This  implies  some  inter-forces  office  In  charge  of  organizing  the 
communication  nets  and  channels. 

It  is  clear  In  this  case  that  the  pure  implementation  of  common  standards  (stanags,  AdatP)  does  not 
fulfill  the  need  for  interoperability.  This  requires  additional  tasks,  to  be  done  commonly  by  all  parties. 
Moreover,  complete  Interoperability  cannot  be  guaranted  unless  the  participants  utilize  the  same  hardware 
and  the  same  software.  If  not,  the  amount  of  trials  and  tests  that  it  would  necessitate  Is  well  beyond  the  feasible 

This  exemple  learns  two  lessons. 

First,  common  standardization  cannot  ensure  interoperability  In  all  cases. 

Second,  some  requirements  in  that  field,  given  the  amplitude  and  the  difficulty  of  the  tasks  to  be 
performed,  may  lead  to  cooperative  work,  including  the  Industrial  one. 


Ill  ■  MODULAR  AVIONICS  -  AN  APPLICATION  STUDY 


Modular  avioriics  is  another  field  where  cooperative  approaches  are  needed,  from  the  design  phases 
on,  in  order  to  ensure  a  certain  level  of  interoperability. 

This  part  of  the  lecture  is  divided  in  four  chapters  : 

-  review  of  the  concepts, 

•  review  of  the  programmes, 

-  applicability  to  an  european  fighter  aircraft, 

-  conclusion. 


Ill'l  •  The  Concepts 

Actual  avionics  systems  are  composed  of  pieces  of  equipment  (black  boxes),  connected  to  several 
data  nets  (busses),  each  of  which  performs  one  or  more  functions.  Each  box  is  optimized  for  Its  functions,  and 
the  system  architecture  is  fitted  to  the  missions  of  the  aircraft,  taking  into  account  the  constraints,  such  as  the 
arrangement  of  the  equipment  cases,  the  volumes,  weights,  consumption  of  thehardware,  the  cost/performance 
ratios,  etc.  The  system  components  are  defined,  in  theory,  following  a  functional  analysis  which  leads  to 
determining  and  sizing  the  necessary  functions  and  to  assign  them  to  such  or  such  box.  There  are  however  some 
functions  that  can  only  be  completely  described  during  the  development.  In  such  a  case,  the  sizing  of  the 
material  resources  Is  defined  with  some  margin.  This  is  also  done  In  order  to  allow  the  future  system  evolution 
(pre-planned  product  improvement),,  whenever  possible.  There  Is  obviously  In  that  approach  some  potential 
problems,  such  as  under-  or  over-estimation  of  the  capabilities  and  performances  of  the  equipment. 

In  addition,  given  the  increasing  complexity  and  integration  of  the  functions  and  the  number  of 
missions  in  one  hand,  and  the  technological  break  through  in  the  other  hand,  that  kind  of  architecture  has  today 
some  clear  drawbacks. 

This  is  true  at  the  technical  level,  because  in  addition  of  the  problems  already  mentionned,  it 
induces  very  important  data  exchange  volumes,  and  thus  an  increasing  complexity  for  the  communication  nets. 
The  data  fusion  capability  is  also  bounded  by  the  multi-location  of  information  and  of  the  related  processing. 
Consequently,  integration  and  validation  become  difficult  to  deal  with. 

At  the  operational  level,  the  availability  and  survivability  are  hindered,  because  redundancies  of 
functions  are  only  possible  by  doubling  the  hardware  that  implement  them,  which  Is  not  allways  possible  and 
is  only  efficient  after  one  first  deficiency. 

For  maintenance  purposes,  each  failure  leads  to  the  replacement  of  one  (at  least)  box.  The  spare 
parts  stocks  are  therefore  heavy  and  costly,  and  many  skilfuil  people  are  needed. 

As  far  as  costs  are  concerned,  some  drawbacks  have  already  been  showed  (maintenance, 
availability).  Some  other  ly  in  the  black  boxes  approach,  due  to  the  separate  deve'opment  and  acquisition  of 
each  of  them,  with  generally  very  few  common  components,  which  obviously  multiplies  the  spendings. 

The  modular  avionics  offers  to  cure  these  illnesses. 

The  main  idea  is  to  gather  within  a  small  number  of  digital  centers  all  the  digital  processings, 
which  represent  the  large  majority  of  the  future  systems.  One  such  center  is  composed  of  an  electronic  rack, 
in  which  standardized,  interchangeable  processing  elements  are  plugged. 
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The  potential  advantages  of  that  concept  can  be  described  as  follows. 

All  the  functions  of  one  type,  realized  up  to  now  by  a  piece  of  equipment  or  another  one,  are 
performed  by  generic  modules.  The  number  of  the  different  modules  (electronic  boards)  needed  is  therefore 
much  lower  for  the  entire  system.  This  reduces  the  complexity  of  the  system  and  the  development  costs  (and 
the  production  costs  because  of  higher  volumes). 

The  modules  are  provided  with  full  self-test  capabilities,  in  order  to  allow  the  detection  and 
localisation  of  the  failures  on  one  of  them.  They  are  replaceable  in  line.  Thus,  the  maintenance  is  highly 
simpler,  and  the  spare  stocks  are  less  voluminous  and  less  expensive. 

One  process  can  be  realized  by  whatever  module  of  the  right  type  in  the  rack.  The  related 
operational  software  is  stored  in  mass  memories.  This  allows  multiple  path  reconfiguration,  with  an  installed 
capacity  much  lower  than  needed  with  classical  architectures.  The  resulting  availability  and  survivability  are 
increased  significantly,,  up  to  the  point  where  the  spare  modules  in  a  rack,  together  with  their  high  reliability 
allow  to  start  a  mission  with  an  initial  failure  ratio  without  loosing  every  reconiiguralion  capability. 
Theoretically,  the  scheduled  maintenance  operations  may  adequately  ensure  the  needed  availability. 

The  processing  capacity  provisions  may  also  be  utilized  for  system  improvements  and  makes  them 
easier  and  cheaper. 

Modular  avionics  shall  globally  allow  the  system  volumes,  weights  and  power  consumption  to 
decrease,  with  the  synergetic  regroupment  of  functions  (in  that  area,  the  comparison  with  other  solutions 
must  be  done  considering  equivalent  capacities,  in  particular  in  the  field  of  reconfiguration),  and  the 
reliability  to  raise  because  of  different  factors  (use  of  leading  edge  technology  for  every  module,  lower 
dissipated  power  and  interconnection,  etc). 

It  IS  however  at  the  financial  level  that  the  benefits  must  be  definitive,  particularly  in  the  context 
of  diminishing  defense  budgets.  In  that  area,  the  reduction  factors  have  been  raised  above  ;  in  acquisition  cost 
(for  development,  with  the  reduced  number  of  different  hardware,  and  of  the  associated  tools  for  software  and 
validation  too,  and  for  production)  and  in  life-cycle  cost  (maintenance,  logistics,  improvements). 

It  must  be  clear  that  the  ability  to  reduce  costs  with  depends  heavily  of  the  obtained  level  of 
standardization.  The  more  platforms  will  make  use  of  the  same  modules,  the  more  attractive  will  be  the  scale 
savings.  This  is  the  reason  why  the  success  of  modular  avionics  lies  in  its  universal  application  to  every 
military  aircraft,  in  the  same  way.  This  is  particularly  true  in  Europe,  where  the  national  military  fleets  are 
not  large  enough  to  completely  achieve  the  potential  savings,  with  regards  to  the  Investment  that  is  necessary 
to  develop  the  concepts. 

In  that  wide  area,  the  completion  of  common  standards  to  several  nations  requires  to  take  into 
account  the  specific  needs  and  constraints  of  each  of  them  ;  here,  the  need  for  standardization  leads  to  a  high 
degree  of  cooperation  between  the  nation,  at  both  governmental  and  industrial  levels. 

This  brings  to  a  new  sophisticated  kind  of  interoperability.  The  modular  avionics  concepts  open  the 
way  towards  new  objectives  :  be  able  to  implement  on  a  platform  a  function  that  was  developped  for  another 
one,  by  means  of  standardized  hardware  and  software,  and  to  maintain  the  systems  of  several  aircraft  with 
common  means  (tools  and  spare  parts).  These  objectives  are  ambitious,  but  not  irrealistic  from  a  technical 
point  of  view.  They  are  perhaps  one  of  the  key-points  for  our  ability  to  keep  a  highly  efficient  defense  with 
limited  budgets. 


111-2  •  The  programmes 


The  modular  avionics  concepts  have  come  out  in  the  United-States,  in  the  frame  of  the  PAVE  PILLAR 
programme  conducted  by  the  USAF  Wright  Laboratories.  This  programme  was  started  in  1982  to  provide  the 
preliminary  architecture  definition,  and  was  terminated  in  1987  with  the  production  of  detailed  design 
specifications  for  the  architecture. 

On  that  basis,  a  US  tri-service  committee,  the  JIAWG  (Joint  Integrated  Avionics  Working  Group), 
was  settled  to  identify  and  develop  joint  avionics  components  and  software,  for  application  on  the  Advanced 
Tactical  Fighter  (ATF)  and  the  Light  Helicopters  family  (LHX). 


In  Europe,  several  projects  have  been  launched  in  that  a.-’ea. 

In  Germany,  the  NAS  (Neue  AvionikStruktur),  started  in  1986,  is  intended  to  define  the  next 
generation  of  avionics  suite  and  to  investigate  its  applicability  in  retrofit  programmes.  Its  phase  1 ,  terminated 
in  1988,  provided  a  concept  definition  for  advanced  modular  avionics  and  a  concept  evaluation.  In  phase  2, 
started  in  1989,  a  risk  reduction  demonstration  for  subsequent  developments  has  been  undertaken,  and  will 


lead  in  1991  to  preliminary  architecture  specifications. 

In  the  United  Kingdom,  a  continuous  research  programme  is  running  since  1986,  for  identifying 
relevant  technology  and  concepts  and  modeling  life-cycle  cost  benefits.  Subsequent  work  has  been  aimed  at 
investigating  critical  areas.  A  flexible  research  rig  is  being  developed  that  will  enable  new  concepts  and 
components  to  be  tested. 

In  1988,  the  UK  MOD  began  a  programme  to  demonstrate  advanced  modular  avionics  architecture  ; 
the  A3P  (Advanced  Avionics  Architecture  and  Packaging).  The  first  phase,  which  is  complete,  was  intended  to 
study  emerging  concepts  and  technologies  and  to  <»ssess  the  benefits  in  operational  performance.  Phase  2  will 
consist  of  subsequent  architecture  definition  and  pi.ases  3  and  4  of  validation  of  the  feasibility  and  of  the 
definition. 


In  France,  the  development  of  data  processing,  high-speed  data  bus  interface  and  mass  memory 
modules,  compliant  with  the  PAVE  PILLAR  standards,  was  began  in  1988,  in  cooperation  with  the  United- 
States  (USAF).  Validation  is  expected  in  1992.  The  applicability  of  a  modular  avionics  suite  to  a  fighter 
aircraft  has  been  studied  in  an  effort  started  in  1989.  The  results  of  that  study  will  be  adressed  in  the  next 
chapter.  It  willbe  followed  by  a  definition  and  validation  phase,  in  the  frame  of  an  exploratory  development,  A3 
(Architecture  Avionique  Avancee).  Some  risk  reduction  studies  are  also  started  in  1991. 

All  these  efforts  require  the  knowledge  of  many  aeronautical  compagnies,  and  must  be  coordinated 
in  order  to  ensure  the  convergence  towards  common  specifications.  The  BNAE,  in  its  role  of  technical  support 
for  future  standards,  has  been  tasked  to  do  that  coordination,  for  the  purpose  of  which  several  working  groups 
have  been  formed,  which  are  comprised  of  members  from  the  whole  french  aeronautical  industry  and  from  the 
DGA 


In  another  hand,  several  efforts  f.-  .a  oeen  Initiated  for  the  application  of  the  concepts  of  modular 
avionics  in  the  field  of  the  CNI  (Communication.  Navigation,  Identification).  In  the  United-States,  the  IONIA 
(Integrated  CNI  Avionics)  led  to  the  realization  of  advanced  development  models  which  integrate  the  CNI 
functions  in  the  2Mhz-5(3Hz  spectrum  and  whose  evaluation  has  begun  in  1990.  In  the  United  Kingdom,  the 
RAE  (Royal  Aircraft  Establishment)  has  realized  a  technology  demonstrator  designed  to  show  the  capability  of 
an  integrated  communications  suite.  In  Germany,  the  NAS  has  dealt  with  the  CNI  and  in  France,  the  need  for 
integrated  CNI  and  the  associated  architecture  are  being  studied  under  the  SIERA  project  (Syst^me  Int^gr^ 
d’Equipements  de  Radio  A6roport6s),  lauched  in  1990.  The  results  will  form  the  bases  of  an  exploratory 
development  to  be  initiated  in  1991,  that  will  be  aimed  at  the  architecture  validation. 

This  brief  listing  shows  that  the  different  countries  have  the  same  preoccupation  and  the  same 
general  objectives.  But  the  related  efforts  are  national  ones.  As  has  been  demonstrated  earlier,  getting 
international  standards  in  that  domain  necessitate  extensive  cooperation.  This  requirement  is  still  enforced  by 
the  heavyness  of  the  investment  involved  In  the  validation  of  a  modular  architecture  for  the  whole  avionics 
suite. 

This  is  the  reason  why  the  four  countries  above  mentionned  (USA,  UK,  GE,  FR)  have  worked  since 
1988  to  the  initiation  of  a  cooperative  programme  for  the  definition  and  validation  of  a  common  avionics 
architecture,  aiming  at  application  in  the  years  2000-2010  timeframe.  It  is  the  ASAAC  (Allied  Standard 
Avionics  Architecture  Council).  Its  mission  is  to  develop  the  technical  specifications  for  an  A3  consisting  of 
functionally  interchangeable  (form,  fit.  function,  interface),  integrated  avionics  modules  that  can  be  used  by 
different  aircraft  as  needed  to  perform  their  mission.  The  ASAAC  end  objective  is  to  propose  a  set  of  validated 
Stanags  for  a  common  A3  and  associated  avionics  building  blocks  (common  modules),  allowing  to  ensure  their 
interchangeability. 

A  partcular  emphasis  will  be  put  on  core  avionics  and  the  CNI.  however,  the  programme  will  tackle 
the  problems  related  to  the  entire  sensors  system  in  an  aircraft.  It  will  comprise  several  phases  ;  definition, 
validation,  evolutions. 

The  ASAAC  is  the  object  of  a  memorandum  of  understanding  signed  by  the  ministries  of  defense  of 
Gerniany,  the  United  Kingdom  and  France  in  1990.  Due  to  budgetary  constraints,  the  United-States  DOD 
(USAF)  was  not  able  to  sign  it  at  that  time,  although  it  had  participated  very  actively  to  its  preparation.  It 
shall  do  so  In  1991.  By  signing  this  memorandum,  the  ministries  recognise  that  their  main  emphasis  in  future 
avionics  standardization  lies  within  ASAAC.  For  the  european  countries,  this  will  lead  to  reorient  towards  this 
cooperative  programme  most  of  the  actions  above  mentionned  that  are  not  yet  started,  such  as  the  exploratory 
developiiienis  A3  and  SIERA  in  France. 


III-3  -  Application  of  modular  avionics  to  an  european  fighter  one  example 
SJ _ Oblectives 


Applying  the  modular  avionics  concepts  to  an  existing  aircraft  raise  a  number  of  problems  that 
have  to  be  studied,  in  such  a  case  indeed,  some  conslaining  factors  tie  in  the  fact  that  a  number  of  elements  are 
already  defined  and  shall  not  hopefully  or  cannot  be  modified.  This  is  conditionning  the  ability  to  examine  the 
feasibility  to  carry  out  these  concepts,  particularly  for  a  mid-life  update.  It  is  moreover  a  mean  to  mesure  the 
advantages  over  classical  architectures. 

In  order  to  investigate  that  question,  the  SITE  has  awarded  a  contract  to  the  french  industry  dealing 
with  the  implementation  of  modular  avionics  on  the  Rafale  aircraft.  It  has  been  carried  out  by  five  major 
aerospace  companies  (Dassault  Aviation,  as  lead  contractor,  Dassault  Electronique,  Sextant  Avionique,  SAGEM 
and  Thomson-CSF)  and  was  terminated  in  mai  1991. 

The  main  objectives  were  ; 

•  getting  the  bases  of  a  modular  architecture  that  could  be  used  for  the  following  developments  in 
France  and  in  cooperation, 

-  examining  the  characteristics  affecting  the  whole  system, 

■  evaluating  the  degree  of  applicability  of  the  main  concepts  to  an  existing  platform,  and  the  relates 
constraints, 

-  determining  a  set  of  standardisable  modular  resources  with  the  technology  available  today. 

The  main  constraints  taken  into  account  were  : 

-  the  already  defined  arrangement  of  the  equipement  cases  and  of  the  volume  available  for  avionics, 
the  utilities  definition  :  electric  power  generating,  cooling  and  conditioning  systems, 

-  the  security  objectives  related  to  the  very  low  level  and  terrain  following  missions. 

The  operational  functions  are  those  airready  defined  or  planned,  with  the  hypothesis  that  the 
functions'  architecture  is  Independant  of  the  physical  organization  on  which  it  is  projected.  The  aim  of  the 
study  is  not  a  global  validation  of  the  concepts,  but  to  propose  a  modular  construing  of  the  physical  resources 
representing  the  system  architecture  (the  ANS  :  Attack  and  Navigation  System),  considering  identical 
functions,  and  to  highlight  the  benefits,  drawbacks  and  constraints. 


3-2  Hvoothesea 

The  fundation  for  determining  the  ANS  specifications  are  the  operational  functions  (OF)  that  it 
must  fulfill.  In  the  frame  of  this  study,  only  the  main  OF,  which  affect  directly  the  system  definition,  i.e. 
which  allow  to  dimension  It,  have  been  considered.  Other  minor  functions  coulb  be  added,  but  without  inc  jcing 
heavy  modifications  of  the  physical  resources.  The  considered  OF  were  : 

-  navigation 

control 

localization/updates 
approach  and  landing 
flight  management, 

-  communications  (clear  and  jammed  modes),. 

-  identification, 

-  aircraft  systems  (utilities)  management, 

-  Man-Machine  Interface  (MMI), 

•  breakdoown  and  alarms  management, 

-  on-line  maintenance, 

-  mission  preparation/restitution, 

-  air  to  air  fire-control, 

-  air  to  ground  fire-control, 

-  very  low  altitude  flight, 

-  self-protection, 

-  tactical  situation  awareness. 

In  the  already  defined  system,  these  OF  are  realized  by  means  of  material  resources  comprising  29 
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black  boxes  and  3  multiplexed  Stanag  3910  busses. 

It  is  worth  to  note  thet  the  fly-by-wire  system  is  not  part  of  the  study,,  and  that  the  resources 
reiated  to  the  self-protection(ECM)  and  the  forward  looking  optronic  (FLIR)  systems  were  not  taken  into 
consideration,  because  of  lack  of  sufficient  progress  in  their  definition  at  the  lime  of  the  study. 


3:3-MethQd 

From  a  system  point  of  view,  moduiar  avionics  run  into  notions  like  fault  tolerance  and  dynamic 
reconfiguration  of  the  functions.  This  is  the  reason  why  a  breakdown  struc'ured  approach  into  boxes  and 
elementary  modules  (LRM  :  Line  Replaceable  Modules)  cannot  lead  to  an  optimized  architecture,  because  It  doer 
not  lake  into  account  every  possible  regroupmeni  and  commonality  of  the  processing  treatments,  nor  their 
possible  standardization. 

The  adopted  method  is  a  top-down  approach,  starting  from  the  existing  results  of  the  ANS  functiona 
analysis.  In  a  first  stage,  the  defined  OF  have  been  gathered  within  some  entities  having  physical 
characteristics  of  the  same  nature  :  the  Homogeneous  bnlilies  (HE), 

That  approach  allows  to  determine  the  different  primary  components  that  are  capable  of  fulfilling 
one  function  with  close  relation  to  their  paterial  caracterisrics  :  the  Malerial/Functional  Modules  (M/F-M). 
For  instance,,  there  are  : 

-  a  multispectral  receiver  module,  whose  function  is  the  multispectral  RF  reception, 

-  A  DSP  module  (Digital  Signal  Processor),  whose  function  is  the  execution  of  one  or  more  digital 
signal  processing  algorithms, 

-  etc. 

At  that  stage,  a  M/F-M  is  not  a  LRM,  because  commonalities  leading  to  physical  module 
standardization  has  not  been  sought.  In  addition,  one  M/F-M  may  be  composed  of  several  LRMs.  This 
partitioning  allows  to  : 

-  assess  the  different  processings  associated  to  each  M/F-M  and  to  identify  their  specific 
characteristics, 

-  determine  the  Inpout/Oulpul  of  each  of  them,  from  an  informational  point  of  view  (type,  flow,, 
caracterisrics  of  the  data)  and  from  the  physical  point  of  view  (type  of  link,  encoding,  frequency,  throupul, 
etc),, 

-  assess  the  constraints  related  to  each  M/F-M  :  location  in  the  aircraft,  temporal  (dating, 
response  time,  synchronization),  working  safely,,  confidentiality  (red/black  isolation),,  power  supply, 
volume,,  conditioning,  etc. 

Each  M/F-M  being  defined.  It  is  possible  to  envisaged  their  gathering  according  to  such  criteria  as 

-  safely  (gathering  in  one  rack  redondani  modules,  or  separating  two  parts  in  order  to  avoid  a 
simple  failure  to  hinder  a  whole  function), 

-  vulnerability  (physical  separation  of  subsets  for  damage  hardening  purposes), 

-  facilitating  the  integration  and  validation  (by  homogenizing  the  functions  in  one  rack), 

•  minimizing  the  data  throughput  between  racks  (oy  gathering  the  modules  exchanging  a  great 
volume  of  information  among  them),, 

and  taking  into  account  such  constraints  as  : 

-  the  number  of  LRM  in  a  rack, 

-  the  number  of  racks  in  a  case, 

the  disposal  anc'  arrangement  of  the  cases, 

-  the  maximum  powe,'  consumolion  of  a  rack, 

-  the  number  of  links  to  a  bus, 

•  the  maximum  distance  between  transceiver  on  a  bus 

-  etc. 

This  lead  to  defining  7  Homogeneous  Entities,  as  shown  on  figure  3  ; 

-  HE1  :  Fly-by-wire  and  powerplani  system  (not  studied) 

-  HE2  :  Aircraft  Systems  (utilities)  Interface  (ASI) 

-  HE3  :  CNI  (Communicr’iion,  Navigation,  Identification) 

-  HE4  :  Core  system 

-  HE5  :  MMI  (Man/Machine  i"'...  dace) 
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-  HES  :  SSI  (Stores-System  Interface) 

-  HE7  :  REO  (Radar,  ECM,  Optronics) 

On  figure  3  appears  a  System  Communication  Net  (RCS  Roseau  de  Communication  Syst^me),  which 
reflects  the  total  Integration  of  the  architecture.  It  is  in  fact  composed  of  sub-nets. 

Figure  4  shows,  as  an  example,  the  break-down  of  HE2  into  M/F— M.  HE2  comprises  the  following 
sub-systems  ;  landing  gear,  electric  power,  starting,  conditioning  and  fuel.  The  content  of  the  four  M/F— M  Is 

-  sensors/actuators 

They  may  be  taps,  valves,  electro-valves,  pumps,  gauges,  tachymeters,  switches,  etc.  As  afsr  as 
the  electic  supply  is  concerned,  they  are  mainly  switching  and  protection  units. 

-  sensors/actuators  interface 

This  module  realizes  the  electrical  Interfaces  of  all  sensors  and  actuators  for  each  sub-system. 

-  sensors/actuators  signal  concentration 

It  collects  every  signal  generated  by  each  interface  to  allow  their  processing  by  the  management 
module.  It  may  be  Implemented  on  the  same  LRM(s)  as  the  interface  M/F— M. 

-  resources  management 

This  module  gathers  the  intelligent  part  of  each  sub-system.  It  realizes  the  processing  of  the 
controls,  regulation  and  supervision  of  every  circuit,  of  the  failure  analysis,  etc.  It  is  linked  to  the  RCS  in 
order  to  exchange  data  with  the  other  HEs. 

This  HE  necessitate  some  redondancies  and  reconfiguration  capacities  at  control  and  management 
level,  in  order  to  ensure  a  sufficient  availability,,  and  some  supervision  and  data  merging  mechanisms  for 
safety  purposes. 

The  other  HEs  are  comprise  : 

HE  3  &  7  fCNI  and  REO) 

Antennae 

Hyper-frequency  stage(s)  (analog) 

Pre-processor  stage(s)  (digital) 

Signal  processing  stage(s) 
resources  management 

UEKCore  system) 

There  is  hero  one  sole  M/F-M,  which  realizes  the  following  : 

-  Technical  management 

initialization 
ground  maintenance 
sensor  fusion 

information  synthesis  (localization,  tactical  siluaticn,  malfunctions) 
resources  management  (power  supply,,  compatibility,  sensors,  armaments) 

-  Mission  control 

cooperation 

flight  conduct  (elaborating  the  trajectories  and  the  guidance  and  control  Information) 
macro-functions  such  as  fire  controls,  counter-measures,  flight  management 

-  failures  and  alarms  management 

-  System  management 

-  MMI  management 

synthesis 

displays  assignment 
controls  assignment 

-  Mass  memories  management 

map  data  base 

mission  preparation/restitution  data  base 
reconfiguration  software 


H£5(IHS) 

Displays  and  controls 

Video  Interface  and  concentrator  interface 


4E-9 


Graphic  and  signal  generation  and  commands  interpretor 
MMI  resources  management 

h£S(SSI) 

The  stores  interfaces  are  standardized  following  the  MIL-STD-1760.  The  interfacing  and 
distribution  functions  are  implemented  by  a  specific  MIL-STD-1760  interface  module  (Stores  I/O). 


3-d...  Results 

3-4-1  General  architecture 

Based  on  the  previous  functional  breakdown,  a  general  architecture  has  been  defined.  It  is  shown  on 

figure  5. 

It  presents  an  intermediate  solution  for  modular  avionics,  since  some  sub-systems  are  not 
completely  integrated  :  REO,  CNI  and  flight  control. 

The  main  characteristics  are  as  follows. 

Core  system 

It  is  the  heart  of  the  whole  system  and  it  administers  the  entire  avionics  suite  in  association  with  a 
set  of  technical  resources  (sensors  and  MMI)  located  in  the  other  HEs. 

Global  bus  definition 

The  processing  (or  management)  racks  are  linked  together  by  a  global  bus.  In  order  to  avoid 
common  mode  failures  due  to  the  fact  that  rack  intercommunication  interface  are  obligatory  waypoints,  it  is 
necessary  to  make  use  of  two  global  busses  to  which  are  connected  every  HEs.  This  is  a  high  speed  redondant 
bus,  like  HSDB  or  HSRB  (high  Speed  Ring  Bus). 

Secured  system  architecture 

Taking  into  account  the  very  low  altitude  (VLA)  function  leads  to  dispose  of  a  dual  architecture  In 
order  to  demonstrate  the  required  safety  level.  This  strengthens  the  need  for  two  global  busses,  with  connectior 
to  both  ones  of  the  related  sensors  (radar,,  radio-altimeter,,  terrain  data  base),  of  the  Core  system  and  the 
flight  control  system. 

Secured  Core  system 

The  Core  system  elaborates  the  VLA  trajectories.  It  must  then  be  secured.  This  has  led  to  separate  il 
into  two  sub-sets  in  order  to  ensure 

-  the  VLA  processing  redundancy 

-  a  lower  physical  vulnerability 

-  the  VLA  commands  fusion. 

However,  some  safety  mechanisms  within  one  rack  could  be  envisaged,  which  would  be  more 
efficient  than  within  one  classical  black  box  because  of  the  dual  backplane  bus  and  the  possibility  to  duplicate 
and  isolate  the  processes  on  different  LRMs. 

Notions  of  data  base  and  dispatching  bus 

Some  functions  utilize  an  important  volume  of  stored  data.  These  data  users  are  multiple, 
especially  when  considering  the  software  reconfiguration  requirements,  in  case  of  failure  or  with  regards  to 
adapting  it  to  different  missions  or  system  configurations.  This  leads  to  propose  a  "data  base"  rack,  which 
comprises  all  necessary  storage  resources  and  allows  the  access  to  all  HEs. 

The  volume  of  transfered  data  may  be  very  high,  so  there  is  a  special  bus  for  that  purpose,  which 
avoids  the  global  bus  saturalion;  the  dispatching  bus.  It  may  be  the  same  type  of  bus  as  the  global  one  in  order 
to  achieve  standardization  (but  for  the  Rafale,  a  3910  would  be  sufficient). 

Notion  of  sensor  bus 

There  is  a  tremendous  need  of  communication  between  some  M/F-Ms  of  one  HE  (for  instance, 
between  image  building  and  graphic  generation  in  the  MMI,  between  the  pre-processor  and  the  DSP  in  the  CNI, 
or  between  the  arithmetic  unit  and  the  PSP  (Programmable  Signal  Processor)  in  the  radar,  wilh  throughputs 
of  about  100  Mbits/s).  When  these  functions  are  located  in  different  racks,  they  need  a  serial  (because  of  the 
distance  between  the  racks),  point  to  point,  100  Mbits/s  bus  in  order  to  exchange  data  :  the  sensor  bus. 
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Notion  of  control  and  status  bus  (CS  bus) 

The  analysis  of  the  HEs  physical  breakdown  shows  a  low  band  communication  need  for  transmitting 
such  information  as  controls  and  commands  and  status  data.  This  is  especially  the  case  for  the  many  MMI 
resources  located  In  the  cockpit :  there,  a  1553B  bus  fits,  but  must  be  doubled.  This  occurs  also  between  some 
LRMs  of  the  ASI  and  SSI,  where  a  1553B  Is  oversized.  In  that  case,  a  RS422  type  bus  should  fit. 

Integration  of  the  Inertial  Navigation  Units  (INU)  into  the  FCS 

The  INU  resources  can  be  split  into  two  sets  ;  the  Inertial  sensor  with  its  supervision  electronics, 
and  the  data  processing  which  calculates  the  pure  and  optimal  inertial  data.  A  hybridization  of  the  inertial 
sensors  to  the  Flight  Control  System  sensors  allow  to  fuse  information  and  to  strengthen  the  validity  of  the 
localization  data,  for  that  purpose,  the  inertial  sensors  are  integrated  In  the  FCS. 


3-4-2  Physical  breakdown 

Each  HE  is  splitted  into  LRMs.  The  modules  format  is  double  Europe  (an  implementation  study  has 
been  carried  out  with  SEM  E  modules,  but  the  equipement  cases  arrangement  and  volumes  are  not  optimized  for 
that  format). 

Two  types  of  racks  have  been  defined 

One  has  a  capacity  of  40  LRMs.  It  will  be  used  for  HEs  comprising  a  great  number  of  I/O  modules 
and  a  small  proportion  of  connections  to  the  backplane  parallel  busses. 

Such  a  bus  being  generally  capable  of  a  maximum  of  15  terminal  units,  a  second  rack  with  a 
capacity  of  18  modules  is  necessary.  Its  size  is  : 

Length  324,5  mm 

Width  220  mm 

Height  273  mm 

Volume  19,5  liters 

The  40  modules  rack  is  twice  this  volume. 

The  composition  of  each  HE  and  the  module  list  is  presented  hereunder.  There  appears  some 
memory  modules,  which  are  related  to  <he  mechanisms  of  reconfiguration  and  dynamic  assignment  of  the 
resources.  Today,  such  modules  are  proposed  with  a  capacity  of  4Mby1es,  which  is  enough  for  most  of  the  HEs. 
However,  capacities  of  twice  or  four  time  higher  are  expected. 

HE  ASI 

This  HE  comprises.  In  a  40  modules  rack  : 

-  a  processing  set,  in  charge  of  managing  all  functions.  The  reconfiguration  principles  of  modular 
avionics  should  allow  to  fulfill  the  requirement  for  safety  and  reliability, 

-  a  I/O  set,  with  the  redundancy  of  the  interfaces  directly  implemented  on  the  LRMs. 

A  CS  bus  performs  the  information  exchanges  between  the  two  sets.  The  LRMs  of  the  processing  set 
are  connected  via  a  parallel  backplane,  PI-BUS  type,  bus. 

The  list  of  the  LRMs  is  as  follows. 


Ssl  LBM  Number 

Processing  CPU  32  bits  RISC  2 

"  Memory  2 

“  global  bus  Coupling  2 

‘  CS  bus  Coupling  2 

“  Power  supply  3 

Sub'Total  1  1 

I/O  Discrete  Input  5 

"  Analog  Input  3 

“  Discrete  Output  3 

“  Power  Output  2 

‘  Specific  Input  1 

“  Specific  Output  1 
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“  Power  Sup.  (or  sensors/acl.  2 

Sub-Total  1  7 

Total  2  8 

Spares  1  2 


HESS! 

The  breakdown  is  similar  to  ASI,  with  extra  coupling  to  1553B  (for  store  interface)  and 
dispatching  (for  distribution  of  stored  data  to  the  stores)  busses. 

The  list  of  the  LRMs  is  as  follows. 


Sal  LBM 

Processing  CPU  32  bits  RISC  2 

"  Memory 

“  global  bus  Coupling 

“  CS  bus  Coupling 

“  Dispatching  bus  Coupling 

“  1553B  bus  Coupling 

“  Power  supply 

Sub-Total 

I/O  28V  Switching 

“  200V  Switching 

“  Armament  safety  Logic 

“  Emergency  safety  Logic 

“  Viddo  Matrix 

“  VidOo  Options 

“  Concentration 

Sub-Total 


tJumbet 

2 

2 

2 

1 

2 

3 

1  4 

9 

6 

1 

1 

4 
3 

2 

2  6 


Total 

Spares 


4  0 
0 
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It  comprises  : 

-  a  processing  set,  in  a  18  LRMs  rack,  connected  to  a  PI-BUS  and  to  the  dispatching  bi'S  (map 
generation,  etc). 

-  a  video  functions  and  MMI  interface  set,  which  handles  the  graphiT  generation  and  the  commands 
acquisition.  It  is  composed  of  a  40  LRMs  rack  and  comprises  2  DSP  modules  for  the  video  processing.  The 
beackplane  bus  may  be  PI-BUS  like,  but  a  throughput  higher  than  25  Mbytes/s  is  probably  necessary.  It  is 
connected  to  the  displays  and  control  terminals  by  the  mean  of  two  1553B  busses  with  a  high  frequency  duty 
cycle  (100  to  200  Hz)  in  order  to  minimize  the  response  times. 

The  breakdown  into  two  sets  is  further  justified  because  their  reconfiguration  mr-rhanisms  are 
different.  They  are  connected  by  a  redundant  sensor  bus. 

The  list  of  the  LRMs  is  as  follows. 


Sg]  LSM  Number 

Processing  CPU  32  bits  RISC  7 

“  Memory  3 

“  global  bus  Coupling  2 

“  Sensor  bus  Coupling  2 

“  Dispatching  bus  Coupling  1 

“  Power  supply  3 

Sub-Total  1  8 

Video  &  Interface  Sensor  bus  Coupling  2 
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Sub-Total 


DSP  2 

Graphic  generator  5 

VidM  processor  2 

Video  insertion  type  1  2 

Video  insertion  type  2  1 

Digital  map  generator  n°  1  1 

Digital  map  generator  n°  2  1 

Digital  map  generator  n°  3  1 

3D  Generator  2 

CS  bus  coupling  2 

audio  analog  I/O  2 

Power  supply  4 


2  7 


Total  4  5 

Spares  1  3 


HECNI 

The  CNI  comprise  the  following  primary  functions  ;  MIDS,  GPS,  IFF,  V/UHF,  R/A,  INU  and  ABC 
(Anemo-Baro-Angle  of  Attack)  sensors.  The  concept  studies  being  under  way  in  France,  a  precise  breakdown 
into  LRMs  has  not  been  obtained.  The  estimates  undertaken  on  the  basis  of  available  information  from  the  ICNIA 
programme  (TRW),  which  would  permit  to  largely  fulfill  the  Rafale  needs  with  70  LRMs,  or  from  the  NAS 
programme  (Germany),  which  corresponds  to  a  CNI  suite  relatively  similar  to  the  Rafale  one  and  which 
comprises  123  LRM  of  26  different  types,  leads  to  a  CNI  HE  with  60  modules,  plugged  in  one  “digital”  rack 
and  three  “hyper-frequency"  racks  (with  12  spare  modules).  Wilh  a  rack  volume  of  19,5  liters,  this 
hypothesis  seems  to  be  pessimistic  when  compared  to  the  SIERA  programme  (Thomson-CSF)  objectives  of  a  45 
liters  volume. 


IdOBEQ 

Since  the  radar  architecture  is  already  modular,,  and  the  other  sub-systems  in  this  HE  have  not 
been  analysed,  the  considered  modules  for  the  radar  are  those  already  defined  :  83  modules  of  about  20 
different  types  (these  modules  are  of  different  formats,  so  the  comparisons  with  other  HEs  are  not  easy). 
Deporting  the  radar  resources  after  the  signal  processing  stage  (PSP)  would  require  an  important  flow  of 
information  (c.a.  500  Mbits/s),  which  could  be  realized  wilh  sensor  busses.  Deporting  the  PSP  is  not 
technically  possible  nowaday. 


HE  Core  system 

It  Is  composed  of  two  identical  1 8  modules  racks  wilh  a  PI-BUS,  and  is  comprised  of : 


LBM  Numt2£i 

CPU  32  bits  RISC  5 

Memory  3 

Global  bus  Coupling  2 

Dispatching  bus  Coupling  1 

Power  supply  3 

Total  1  4 

Spares  4 


j 

i 


HE  Data  Base 

It  has  been  assumed  that  half  of  its  18  LRMs  rack  was  dedicated  to  the  data  base  itself  (which  can  be 


teftr  V.  '  t 
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implemented  with  optical  disks  reader  or  with  hybrid  Si  memories).  The  t  eakdown  into  LRMs  is  then  : 


LBM  Number 

CPU  32  bits  RISC  2 

Memory  2 

Sensor  bus  Coupling  2 

Dispatching  bus  Coupling  1 

Power  supply  2 

DataBase  9 

Total  1  8 

Spares  0 


Synthesis 

The  considered  HEs  are  globally  Implemented  by  moans  of  210  LRMs  dispatched  the  following  way 


bE  f 

lacks  Canacitv 

Nb  LRM 

Spares 

ASI 

40 

28 

1  2 

SSI 

40 

40 

0 

MMI 

58 

45 

1  3 

Core 

36 

28 

8 

Data  Base  9 

9 

0 

CNI 

72 

60 

1  2 

Total 

255 

2  1  0 

4  5 

Except  the  CNI  (60  LRMs),  the  150  remaining  modules  are  of  32  different  types,  the  more 
frequently  used  being  ; 

CPU  32  bits  RISC  23 

DSP  2  (out  of  the  radar) 

Memory  1 5 

Global  bus  Coupling  1  0 

CS  bus  Coupling  4 

Dispatching  bus  Coupling  5 
Sensor  bus  Coupling  6 

15538  bus  Coupling  4 

Power  supply  21 

The  racks  can  be  installed  in  the  equipment  cases  where  the  replaced  black  boxes  were 
previously  housed. 

It  is  worth  to  note  that  some  optimization  have  not  been  taken  into  account  in  these  results,  as  for 
example  for  the  CNI,  or  for  the  global  and  dispatching  busses  which  could  be  identical.  The  results  are  thus 
pessimistic,  compared  to  those  that  could  be  ontained  with  a  complete  compliance  with  the  concepts  of 
modular  avionics. 

This  study  did  not  consider  a  complete  avionics  system.  However,  it  shows  that  the 
implementation  of  the  operational  functions  of  a  small  size  aircraft  like  the  Rafale  is  possible  with  a 
modular  system,  while  fulfilling  the  severe  safely  requirement  linked  to  the  VLA  missions.  No  significant 
benefit  appears  in  terms  of  avionics  volume  or  weight,  but  it  must  be  considered  that  the  reconfiguration 
capabilities  are  greatly  improved,  and  that  significant  spares  are  available  (17%  of  the  installed 
capacity). 


3-5  Conclusion 

This  study  was  a  first  step  in  France  towards  modular  avionics. 

It  allowed  the  industry  and  the  ministry  to  assess  the  feasibility  of  these  new  concepts.  However, 
and  this  Is  not  the  least  lesson,  it  did  not  demonstrate  that  all  potential  benefits  are  obtainable,  especially 
from  a  financial  point  of  view. 


It  has  also  led  to  identify  some  areas  of  high  risk,  such  as  the  packaging  or  the  implementation  of 
a  global  operating  system  being  capable  of  automatic  reconfigurations  within  a  rack,  whose  mastership 
will  still  require  great  efforts. 

The  related  work  will  continue  in  the  frame  of  cooperative  programmes,  such  as  ASAAC,  already 
mentionned,  or  EUCLID  (European  Cooperation  for  the  Long  term  tn  Defense,  whose  Common  European 
Priority  Area  n°  4  is  on  modular  avionics).  This  is  absolutely  mandatory,  in  one  hand  because  of  the 
required  budget  for  carrying  out  such  a  development,  and  in  the  other  one  in  order  to  ensure  the  widest 
standardization  within  NATO,  which  is  the  only  way  to  ensure  an  optimized  use  of  the  resources  and 
interoperability  within  the  alliance. 


IV  -  THE  SOFTWARE  BUS 

The  previous  chapter  shows  an  extensive  use  of  the  arithmetic  'ogic  unit  (CPU)  module  within  an 
avionics  suite.  This  reflects  the  importance  of  that  kind  of  prc  cessing,  which  results  in  exponentially 
growing  software  bulks.  The  necessary  standardization  of  the  CPUs  intends  to  meet  three  main  objectives  : 
physical  Interchangeability,  which  is  ensured  via  the  F3I  specifications, 

-  dynamic  reconfiguration;  this  demands  that  in  one  system,  or  at  least  one  rack,  all  CPU 
modules  are  able  to  work  the  software  stored  in  the  bulk  memory, 

•  portability  of  the  software,  and  eventually  of  the  modules  themselves,  from  a  system  to  another 
cne. 


This  is  inviting  to  infer  the  need  to  standardize  an  unique  Instruction  Set  and  an  unique  Real  Time 
Executive. 

However,  the  solution  has  already  been  investigated  and  has  led  to  some  severe  disappointments. 
The  US  DOD  have  done  so  with  the  MIL-STD-1750A.  Now  it  appeared  that  the  processors  using  this  16  bits 
Instruction  Set  have  been  fast  outmatch  in  performance  by  32  bits  items,  especially  RISC  (Reduced 
Instruction  Set  Computer),  before  their  large  scale  implementation  in  aeronautics.  The  french  MOD 
experienced  the  same  troubles  with  the  CMP  programme  (Calculateur  Militaire  Frangais),  that  was 
intended  to  meet  every  military  need  and  had  practically  no  application,  although  it  was  based  on  a  32  bits 
Instruction  Set. 

Standardizing  an  Instruction  Set  for  all  military  platforms  presents  among  others  the  following 
drawbacks  : 

-  it  is  an  obstacle  to  technological  break-through, 

-  it  precludes  from  utlizing  the  best  available  technology  at  one  time, 

-  it  hinders  to  profit  from  synergy  with  the  professional  sector,  which  in  this  area  benefits 
from  a  much  higher  growth  than  the  military  sector,  both  at  hardware  and  software  tools  levels, 

’  it  implies  substantial  fundings  in  order  to  maintain  the  penormances. 

It  could  be  envisaged  to  use  as  a  standard  an  Instruction  Set  of  the  commercial  shelf.  But  there, 
the  same  objections  arise,  because  any  choice,  be  it  the  good  one  (which  is  very  difficult  to  assess  on  a 
medium  term  basis),  is  considerably  limiting  the  capacities. 

One  potential  solution  to  that  problem  would  be  to  design  a  standard  interface  between  the 
application  software  and  the  real  time  executive  (RTE) :  this  is  the  notion  of  Software  Bus. 

Three  interface  standardization  levels  can  as  a  matter  of  fact  be  defined  ; 

-  one  for  exchanges  between  sub-systems,  or  racks,  by  the  mean  of  multiplex  busses  like  the 

HSDB, 

-  one  for  exchanges  between  modules  within  a  rack,  by  the  mean  of  backplane  busses  like  the  PI- 

BUS, 

-  one  between  the  application  software  of  a  module  and  its  RTE. 

The  objevtive  is  to  obtain  a  complete  portability  of  the  operational  software  from  a 
processor/executive  set  to  every  other  one,  with  the  accepted  constraint  of  recompiling  it  (the  modules  of 
a  same  rack  will  need  a  higher  level  of  standardization,  in  order  to  allow  some  reconfiguration).  This  leads 
to : 

-  a  real  independance  in  regard  to  the  hardware, 

-  the  portability  of  the  applications. 
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software  reuse. 

Within  the  DGA,  the  DEI  (Direction  de  I'Electronique  et  de  I'lnformatique)  has  initiated  some 
actions  in  this  area,  comprising  several  facets. 

A  Real  time  Executive 's  generally  composed  of  several  functionalities  ; 

-  interrupt  handling, 

-  Ada  rendez-vous, 

-  asynchronous  primitives, 

-  I/O  handling, 

'■  distribution  (sharing  of  the  global  executive  into  local  ones,  at  the  module  level,  in  order  to 
meet  in  particular  the  reconfiguration  objectives). 

Some  of  these  functions  exist  in  the  Ada  Runtime  and  is  thus  standardized. 

As  far  as  distribution  Is  concerned,  the  DEI  has  developped  a  complement  to  the  executive,  called 
EXTRA  (Extension  du  RunTime  Ada).  The  targets  are  the  MIPS,  SPARC,  680X0,  88000  and  I  960,  with  the 
Ada  tecnologies  from  Verdix,  Telesoft  and  Alsys,  which  allow  to  cover  a  large  range  of  products. 

Ada  does  not  provide  such  well-known  asynchronous  mechanisms  as  events  or  semaphores. 
However,  the  need  exists,  in  order  to  : 

-  accomodate  existing  application  designs, 

•  support  asynchronous  communication  and  signaling  operations, 

-  enhance  the  application  performance, 

-  enhance  the  application  portability  and  reuse. 

Such  services  can  be  realized  in  pure  Ada  using  the  rendez-vous  mechanism.  However,  it  is  at 
cost  of  extra  server  tasks  and  rendez-vous  operations.  Thus,  the  DEI  has  proposed  a  list  of  primitives  tor 
insertion  In  the  Ada  language.  They  represent  a  coherent  model  of  asynchronous  cooperation  mechanisms 
that  promotes  clean,  efficient  application  architectures  which  avoid  usage  of  non-portable  solutions.  The 
entries  relative  to  these  primitives  are  : 

•  counters  :  “resources"  and  “buffers”,, 

•  states  :  “events”  and  “blackboards”, 

•  pulses  :  “pulses”  and  “  broadcasts”. 

They  are  preliminary  to  the  Software  Bus  notion,  on  which  the  studies  are  just  beginning. 

The  Software  Bus  notion  implies  that  the  requirements  and  constraints  of  all  potential  users 
shall  be  taken  into  account.  This  enforces  once  again  the  need  to  conduct  this  design  in  a  cooperative  way, 
which  could  be  optimally  done  in  the  frame  of  the  international  programmes  on  modular  avionics. 


V  •  GENERAL  CONCLUSION 

This  lecture  does  not  intend  to  deal  with  all  the  avionics  standardization  aspects  in  Europe  :  this 
is  too  large  a  topic.  But  by  considering  some  aspects  of  avionics,  it  intended  to  demonstrate  that: 

-  standardization  and  interoperability  are  substantial  financial  and  operational  stakes  for  the 
future.  In  this  way,,  standardization  itself  is  a  brand  new  requirement,  that  will  have  more  and  more 
importance, 

-  the  objectives  can  only  be  met  by  extensive  cooperation,  at  every  level. 


The  illustrations  to  this  Section  can  be  found  on  pages  4- 16  to  4-20,  which  immediately  follow  the  French 
translation. 
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LA  STANDARDISATION  AVIONIQUE  EN  EUROPE 
par 

IPALGUIBERT 
DGA/OCA6«TTE 
129,  Rue  de  la  Convention 
75731  PARIS  CEDEX  15 


INTRODUCTION 


Get  expose  comprend  cinq  parties  : 

-  Rappel  des  diff^rentes  oiganisations  en  charge  de  la  normalisation  a^ronautique  en  Europe. 

-  Les  rapports  entre  la  standardisation  et  I’interopdrabilit^. 

-  Un  example  de  domaine  pour  lequel  la  standardisation  a  de  fortes  implications  ;  I’avionique 
modulaire. 

-  Un  autre  example  :  le  Sofhware  Bus. 

•-  Conclusion. 


I  •  LES  ORGANISMES  DE  NORMALISATION  EN  FRANCE  ET  EN  EUROPE 


L'organisme  responsable  de  la  normalisation  en  France  esi  I’AFNOR,  qui  depend  du  Minisifere  de 
rindustrie  et  de  I'Am^nagement  du  Territoire.  L'AFNOR  6labore,  en  concertation  avec  des  bureaux  de 
normaliSv.' on  sectoriels,  des  normes  nationates  (NF)  pour  tous  les  secleurs  de  I'industrie. 

Au  plan  europ6en,  I'homologue  de  I'AFNOR  est  ie  C.E.N.  {Comil6  European  de  Normalisation),  qui 
6labore  les  Normes  Europ6ennes  (EN).  C'est  I’AFNOR  qui  repr6sente  la  France  au  C.E.N. ,  de  mime  que 
d'autres  organismes  nationaux  y  reprisentent  leur  pays.  L'industrie  airospaliale  est  reprisentie  au  C.E.N. 
par  I’AECMA,  qui  regroupe  plusieurs  syndicats  professionnels  nationaux.  L’AECMA  est,  pour  le  CEN,  le 
bureau  europien  de  normalisation  dans  le  domaine  airospatial. 

Dans  le  domaine  de  I'aironautique  et  de  I’espace,  un  bureau  particulier,  le  BNAE  (Bureau  de 
Normalisation  de  I'Aironautique  et  de  I'Espace)  a  en  charge  I’iiaboralion  et  la  diffusion  des  normes 
frangaises  (NFL).  Pour  cela,  il  est  en  relation  avec  le  Mmistire  de  la  Difense,  par  le  biais  de  la  DGA,  et 
avec  rindustrie  par  le  biais  du  GIFAS  (Groupement  des  Industries  Frangaises  Aironautiques  et  Spaliales), 
qui  assurent  la  majeure  partie  du  financement  de  son  fonctionnemenl. 

Le  BNAE  peut  aussi  assurer  d'autres  tiches,  telles  que 

■  la  soutien  technique  pour  I’ilaboration  de  nouvelles  normes,  aux  plans  national  et  international, 

•  la  mise  i  I'enquite  en  France  de  projets  de  standards  inlernationaux  ilaboris  par  ailleurs. 

C’est  en  particulier  le  cas  pour  les  standards  OTAN  (Stanags)  en  avionique  (groupes  AVS  et  Al). 

Cela  le  conduit  i  mettre  en  place  un  certain  nombre  de  groupes  de  travail  regroupant  des 
reprisentants  de  l’industrie  et  de  la  DGA. 

II  reprisente  aussi  la  France  d  I’ISO  (International  Standardization  Organization)  dans  son 
domains  (TC  20). 

La  figure  1  montre  les  divers  organismes  en  charge  de  normalisation  en  France,  en  Europe,  au 
sein  de  I’OTAN  et  dans  le  monde,  et  les  relations  entre  eux.  La  figure  2  prOcise  la  participation  des  divers 
pays  aux  diff^renls  offices  de  normalisation  internationaux. 
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II  -  LA  STANDARDISATION  ET  LTNTEROPERABILITE 

II  est  commun^ment  admis  que  I'interopdrabilild  n6cessile  la  conformity  y  des  standards  commons. 
Mais  est-ce  suffisant?  Pour  rdpondre  y  cette  question,  il  est  utile  de  prendre  un  exemple  :  la  liaison  1 6. 

La  liaison  16  est  essentiellement  une  transmission  de  donnyes  protygye,  en  ryseaux,  dyfinie  par  un 
Stanag,  n°  5516,  qui  dycrit  entre  autres  choses  les  messages  possibles,  certains  ytant  obligatoires  et 
d'autres  facultatifs.  L'organisation  des  ryseaux  et  des  messages  est  rygie  par  un  autre  document  OTAN, 
l'AdatP16. 

L'interopyrability,  dans  ce  cas,  consists  simplement  k  pouvoir  communiquer  entre  les  diffyrents 
intervenants  :  Armyes  de  I'Air,  de  Terre  el  de  Mer  d'un  pays,  el  de  plusieurs  pays  alliys.  Pour  cela,  il  faut 
dyfinir : 

-  le  ryseaux  interarmes  ou  interalliys  sur  lequel  tes  informations  seront  ychangyes, 

-  les  messages  qui  seront  ychangys  sur  ces  ryseaux,  et  leur  ordre  d'ymission  par  les  diffyrents 
lerminaux, 

•  le  contenu  formaty  au  bit  prys  de  ces  messages  (champs). 

II  faut  en  fait  organiser  les  trames  d'ychange  des  informations,  de  fagon  similaire  k  ce  que  I'on  fait 
pour  un  bus  multiplexy  du  type  1553B.  Cela  nycessite  la  mise  en  place  d'organismes  interarmes  ou 
internationaux  pour  gyrer  les  ryseaux  LI  6. 

II  est  Clair  dans  ce  cas  quo  I'applicalion  de  normes  communes  (Slanays,  Adal)  ne  suffit  pas  k 
assurer  l'interopyrability.  Celle-ci  exige  un  travail  important  en  common.  De  plus,  elle  ne  pourra  ytre 
vyrilablemeni  garantie  que  si  tous  les  participants  utilisent  le  myme  yquipement  et  le  mSme  logiciel.  Dans 
le  cas  contraire  en  effet,  sa  dymonstration  demanderait  pour  couvrir  tous  les  cas  possibles  une  somme 
d'essais  irryalisable. 

II  y  a  done  deux  legons  k  tirer  de  cel  exemple 

La  premiyre,  e'est  qu'une  normalisation  commune  ne  suffit  pas  loujours  k  assurer 
l'interopyrability. 

la  seconde,,  e'est  que  certains  besoins  d'interepyrability,  selon  la  difficulty  et  I'ampleur  des 
tSches  k  accomplir  pour  I'obienir,  peuveni  enirainer  des  besoins  de  coopyralion,  y  compris  au  niveau 
industriel. 


Ill  •  L’AVIONIQUE  MODULAIRE  •  UN  CAS  D'APPLICABILITE 


L'avionique  modulaire  est  un  cas  exemplaire  de  domaine  oil  l'interopyrability  nycessite  une 
approche  coopyrative  au  stade  de  la  conception. 

Cette  parlie  de  I'exposy  est  dycomposye  en  quatre  chapilres  : 

•  rappel  des  concepts, 

-  les  programmes, 

-  applicability  k  un  avion  de  combat  europyen, 

-  conclusion. 


111-1  •  Les  concepts 

Les  systymes  avioniques  actuels  sont  composys  d'yquipemenis,  qui  rdaliseni  chacun  une  ou 
piusieurs  functions,  reliys  entre  eux  par  plusieurs  ryseaux  d'ychange  d'informations,  les  bus.  Chaque 
yquipement  est  opiimisy  pour  ses  fonctions,  el  I'archiiecture  du  systyme  est  adaptye  aux  missions  de  I'avion 
en  fonction  de  coniraintes  telles  que  I'amynagement  des  soules,  les  encombrements,  poids,  consommation  des 
yquipements,  I’opiimisalion  du  rapport  performance/coOt,  etc.  La  composition  du  systyme  est  yiaborye,  de 
fagon  thyorique,  aprys  une  analyse  fonctionnelle  qui  permet  de  dyfinir  et  de  dimensionner  les  fonctions 
nyccssaircs  et  de  les  attribuer  k  tel  ou  lei  equipement.  Pour  les  fonctions  qui  ne  peuvent  §tre  tolalernent 
dyfinies  ou  dimensionnyes  que  pendant  le  dyveloppement,  on  est  ameny  k  prendre  certaines  provisions  pour 
le  dimensionnement  des  ressources  matyrielles  nycessaires  k  leur  implantation.  II  en  va  de  mSme  pour  les 
yvolutions  futures  du  systymes  (yvolulions  pry-programmyes),  quand  cela  est  possible.  On  le  voit,  il  y  a 
dyjy  ly  un  certain  nombre  de  sources  potentielles  de  probiymes  au  niveau  du  systyme  (sur-  ou  sous- 
yvaiuation  des  capacitys  et  des  performances  des  yquipements). 
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De  plus,  6tant  donn6s  le  nombre,  la  complexild  et  rint6gratlon  croissants  des  fonctlons,  la 
multipicitd  des  missions  et  les  perches  technologiques,  ce  type  d'architecture  pr6sente  aujourd'hui  des 
inconvdnients  certains. 

Au  plan  technique,  car  outre  les  probiemes  d6]^  6voquds  plus  haut,  11  indult  des  volumes 
d'6changes  d'informatlons  Importants  et  done  une  complexit6  crolssante  des  r6seaux  de  communication.  La 
capacity  i  fusionner  les  donndes  est  aussi  ilmlt^e  par  la  multi-localisation  de  ces  donndes  et  des  traltements 
qui  leur  sont  appllquds.  En  consequence,  i'integratlon  et  la  validation  peuvent  devenir  difficllement 
mattrisables. 

Au  plan  operationnel,  la  dlsponlbilite  et  la  sun/ivabillte  sont  limitees  par  le  fait  que  la  redondance 
d’une  fonction  ne  peut  6tre  assuree  qu'en  doublant  1‘equipement  quI  la  realise,  ce  qui  n'est  pas  toujours 
possible  et  n'est  efficace  qu'apres  une  seule  panne. 

Au  plan  de  la  maintenance,  tout  equipement  en  panne  doit  6tre  depose  et  remplace.  II  faut  done 
avoir  un  stock  de  rechange  volumlneux  et  coOteux  et  du  personnel  qualifie  pour  chacun  d'eux. 

Au  plan  des  coOts,  enfin,  outre  ceux  inherents  e  la  maintenance  et  4  la  disponibllite  evoques  ci- 
dessus,  d'autres  Inconvenients  resident  dans  le  fait  qua  cheque  equipement  est  developpe  et  approvisionne 
separement,  avec  tres  peu  de  composants  commons,  ce  qui  a  un  effet  multiplicatif  evident. 

L'avionique  modulaire  se  propose  de  rernddier  4  tous  ces  maux. 

L'idee  directrice  est  de  regrouper  dans  un  nombre  reduits  de  coeurs  informatiques  I'ensemble  des 
traltements  numeriques,  ce  qui  represente  la  quasi-totalite  des  syst4mes  futurs.  Un  coeur  esi  compose 
d'une  etagere  eiectronique  sur  laquelle  sont  enfichees  des  modules  de  traitement  standardises, 
interchangeables. 

Les  avantages  de  ce  concept  sont  en  theorie  les  suivants. 

Toutes  les  fonctlons  de  m6me  type,  iusqu'4  present  realisees  par  tel  ou  tel  equipement,  le  sont  par 
des  modules  generiques.  On  a  done  besoin  d'un  nonbre  significativement  moins  eieve  de  modules  dlKerents 
pour  realiser  un  systems  complet.  Cela  diminue  d’autant  la  complexite  du  systems,  et  permet  d'economiser 
sur  les  coOts  de  developpement  ainsi  que  sur  ceux  de  production  par  effet  de  serie. 

Les  modules  (cartes  eiectroniques)  sont  munis  d’autotests  permettant  de  detecter  et  de  localiser 
les  avaries  sur  I'un  d'entre  eux.  Ils  sont  remplagabies  au  premier  niveau.  Ainsi,  la  maintenance  est 
considerablement  simplifies,  et  le  stock  de  rechanges,  qui  ne  comports  que  des  modules,  est  reduit  en 
volume  el  en  cout. 

Un  traitement  peut  etre  effectu6  sur  I’un  quelconque  des  modules  standardises  du  m6me  type  dans 
une  etagere.  Cela  permet  d'obtenir  des  possibilites  de  reconfiguration  multiples  en  installant  une  capacite 
suppiementaire  pour  la  reconfiguration  en  cas  de  panne  bien  inferieure  4  ce  qui  est  necessaire  avec  une 
architecture  classique.  Les  logiciels  de  traitement  sont  pour  cela  stockes  en  m6moire  de  masse  pour  chaque 
rack.  On  obtient  un  accroissement  de  la  survivabilite  et  de  la  54curit4.  De  plus,  en  fonction  du  nombre  de 
modules  en  reserve,  et  de  leur  fiabillte,  il  est  possible  de  commencer  une  mission  avec  un  certain  taux  de 
panne  Initial  tout  en  ayant  encore  une  capacit4  de  reconfiguration.  ThSoriquement,  on  peut  arriver  4  un 
niveau  de  dlsponibilit4  accru  4  un  point  tel  que  la  maintenance  programrnee  suffirait  4  maintenir  l'a4ronef 
en  6tat  de  combatire. 

Les  reserves  en  capacite  de  traitement  peuvent  aussi  permettre  d’accroitre  les  fonctionnalites  du 
systems  de  fagon  plus  aisee  et  4  moindre  cout. 

L'avionique  modulaire  doit  aussi  permettre  de  diminuer  globalement  les  volumes,  poids  et 
consommations  des  syst6mes  (par  regroupement  des  fonclions,  les  comparaisons  devant  6lre  faites  4 
capacites  egales,  notamment  en  matiere  de  reconfiguration)  et  d’augmenter  la  fiabilite  par  le  jeu  de 
plusieurs  facteurs  (utilisation  de  la  technologie  la  plus  avancee  pour  tous  les  modules,  deverminage  d'un 
petit  nombre  de  prodults,  diminution  de  la  puissance  dissip4e  et  du  nombre  d'interconnections,  etc). 

Mats  e'est  sans  doute  au  plan  financier  que  les  avantages  doivent  6tre  d4terminants, 
particuli4rement  dans  le  contexts  actuel  de  diminution  des  budgets.  Les  facteurs  de  r4duction  ont  4t4 
mentionn4s  plus  haut :  en  coflts  d'acquisition  (de  developpement,  par  le  nombre  r4duit  de  modules 
differents,  mais  aussi  d'outils  associes,  pour  le  logiciel,  les  tests  et  la  validation,  et  de  production,  pour  les 
m§mes  raisons)  et  en  coOts  de  possession  (maintenance,  logistique,  evolutions). 

II  est  Clair  que  la  capacite  du  concept  4  reduire  les  coOts  depend  du  niveau  de  standardisation 
obtenu.  Plus  le  nombre  de  plateformes  utilisant  les  m§mes  modules  sera  eieve,  plus  les  economies  d'echelle 
seront  attractives.  C’est  pourquoi  un  facteur  determinant  pour  la  reussite  de  l'avionique  modulaire  reside 
dans  I'universalite  du  concept  et  son  application  4  I’ensemble  des  aeronefs  militaires  de  fagon  identique. 
C'est  particulieremer.t  le  cas  pour  les  pays  europeens,  pour  lesquels  les  flottes  nationales  d’aeronefs  sont 
trop  peu  nombreuses  pour  profiter  pleinement  des  economies  potentielles. 

Dans  ce  domaine,  tres  vaste,  (’elaboration  de  standards  commons  4  plusieurs  nations  necessite  la 


prise  en  'xxnpte  des  besoins  at  des  contraintes  sp^cifiques  &  chacune  d'elles  :  Id  patliculidremeni,  le  besoin 
do  standardisation  ndcessite  une  cooperation  poussee  entre  las  nations,  aux  niveaux  gouvernemental  et 
industriol. 

Cela  conduit  d  une  forme  d'interopdrabilitd  sophistiqude.  Le  concept  d'avionique  modulaire  ouvre 
en  effet  la  vole  vers  des  objectifs  nouveaux  ;  pouvoir  Installer  sur  un  adronef  une  fonction  ddveloppde  pour 
un  autre,  tant  sur  le  plan  matdrlel  que  logiciel,  et  pouvoir  maintenir  un  systdme  avec  des  moyens  communs 
(outils  et  rechanges)  d  plusieurs  plateformes.  Ces  objectifs  sont  cerles  trds  ambitieux,  mals  pas 
irrdalistes  au  plan  technique.  Ils  sont  peut-dtre  une  des  elds  de  notre  capaeltd  d  maintenir  une  ddfense 
performante  avec  des  moyens  financiers  limitds. 


III-2  -  Les  programmes 

Le  concept  d'avionique  modulaire  a  vu  le  jour  aux  Etals-Unis,  dans  le  cadre  du  programme  PAVE 
PILLAR  mend  par  les  Laboratoires  Wright  de  I'USAP.  Ce  programme  a  dtd  lancd  en  1982  par  I'dtude  de  la 
ddfinitlon  de  I'architecture  et  s'est  termind  en  1987  avec  i'diaboration  des  spdcificatlons  ddtailldes  de 
conception  de  I’avior,:  jue  PAVE  PILLAR. 

Sur  cette  base,  un  groupe  tri-service  a  dtd  mis  en  place  pour  identifier  et  ddvelopper  des 
composantes  at  des  logiciels  avioniques  communs,  destinds  d  dtre  appliquds  sur  I'ATF  et  la  famille  LHX  entre 
autres  ;  le  JIAWQ  (Joint  Integrated  Avionics  Working  Group). 

L'Europe  a  aussi  mis  en  place  plusieurs  programmes  sur  le  sujet. 

En  Allemagne,  Neue  Avionikstruktur  (NAS),  lancd  en  1 986,  esi  destind  d  ddfinir  une  nouvelle 
gdndration  d'avionique  et  d'dtudier  son  application  d  des  rdtrofits  d'adronefs.  II  comprend  une  premidre 
phase  de  conception,  terminde  en  1988,  et  une  deuxidme  phase  de  rdduction  de  risques  qui  doit  aboutir  en 
1991  d  des  spdcificatlons  prdliminaires  d’architecture  avionique. 

Au  Royaume  Uni,  un  programme  continu  de  recherches  est  en  place  depuis  1986  pour  idenlifier 
les  technologies  et  les  concepts  applicables,  dtudier  les  domalnes  criliques  et  moddllser  les  bdndfices  en 
termes  de  coOts.  Dans  ce  cadre,  un  banc  de  recherche  est  ddveloppd  pour  permetire  de  tester  de  nouveaux 

concepts  et  composantes  de  systdmes.  En  1988,  le  programme  A^P  (Advanced  Avionics  Architectures  and 
Packaging  demonstrator)  a  dtd  lancd  pour  dtudier  les  nouveaux  concepts  et  technologies  en  avionique  et 
ddterminer  leurs  avantages  opdrationneis  (phase  1,.  qui  est  terminde),  puis  pour  ddfinir  une  architecture 
(phase  2)  et  valider  sa  falsabilitd  et  sa  ddfinitlon  sur  un  banc  d’ossais  (phases  3  et  4). 

En  Prance,  le  ddveloppement  de  modules  de  traitement  de  donndes,  d'interface  pour  bus  optique  et 
de  mdmoire  de  masse  conformes  aux  standards  PAVE  PILLAR  a  dtd  lancd  en  1988,  en  coopdration  avec  les 
Etats-Unis  (USAF),  pour  une  validation  prdvue  en  1992.  Une  dtude  d'application  de  I'avionique  modulaire  d 
un  avion  de  combat  a  commened  en  1989,  dont  les  rdsultats  seront  abordds  dans  le  chapitre  suivant.  Cette 
dtude  doit  se  poursuivre  par  une  phase  de  ddfinitlon  et  de  validation  d'architecture  dans  le  cadre  d'un 
ddveloppement  exploratoire,  A^  (Architecture  Avionique  Avanede).  Des  dtudes  de  rdduction  de  risques  sont 
aussi  lancdes  en  1991  dans  les  domaines  du  packaging  et  de  la  reconfiguration.  L'ensemble  de  ces  actions 
requierl  les  compdtences  de  nombreuses  socidtds  adronautiques,  qui  doiveni  se  coordonner  pour  assurer  une 
convergence  vers  des  standards  cc,...7tuns.  C'est  naturellement  au  BNAE,  dans  son  role  de  soutii  i  technique 
pour  I'diaboration  de  nouvelles  normes,  qu'd  dtd  confide  cette  tSche,  pour  laquelle  plusieurs  groupes  de 
travail  rdunissant  l'ensemble  de  I'industrie  adronautique  frangaise  et  les  services  de  la  DGA  ont  dtd  erdds. 

D'autre  part,  plusieurs  programmes  ont  dtd  lancds  pour  I'application  des  concepts  d'avionique 
modulaire  dans  le  domaine  des  CNI  (Communications,  Navigation,  Itientification).  C’est  le  cas  aux  Etats- 
Unis,  avec  ICNIA  (Integrated  CNI  Avionics),  qui  a  conduit  d  la  rdalisation  de  moddles  de  ddveloppement 
intdgrant  les  fonctions  CNI  dans  un  spectre  de  2MHz  d  5GHz,  dont  I'dvaluation  a  commened  en  1990.  Au 
Royaume  Uni,  le  RAE  (Royal  Aircraft  Establishment)  a  rdalisd  un  ddmonstrateur  technologique  orientd  vers 
I’dvaluation  des  capacitds  d'un  systdme  intdgrd  de  communications.  En  France,  I'dtude  SIERA  (Systdme 
Intdgrd  d'Equipements  de  Radio  Adroportds),  lancde  en  1990,  a  pour  but  de  ddfinir  les  besoms  en  matidre  de 
CNI  intdgrdes  et  leur  architecture.  Elle  doit  aboutir  au  lancement  d'un  ddveloppement  exploratoire  en  1991 
pour  en  assurer  la  validation. 

Ces  efforts,  plus  ou  moins  importants,  sont  d’oidre  national.  Comme  il  a  etd  montrd  plus  haut, 
I’obtention  de  standards  internationaux  ndeessite  des  coopdrations  importantes  dans  ce  domaine.  Cette 
exigence  est  encore  renforede  par  I'investissement  lourd  que  reprdsente  la  validation  d'une  architecture 
modulaire  pour  l’ensemble  de  I’avionique. 

C'est  pourquoi  les  quatre  pays  ddjd  citds  (USA,  RU,  RFA,  FR)  ont  travailld  depuis  1988  d  la  mise 
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en  place  d’un  programme  en  cooperation  do  definition  et  de  validation  d’une  architecture  avionique 
commune,  visant  des  applications  dans  les  annees  2000-2010.  II  s’agit  de  I’ASAAC  (Allied  Standard 
Avionics  Architecture  Council).  Sa  mission  est  de  developper  les  specifications  techniques  d’une 
architecture  avancee  composee  de  modules  integres  interchangeables  pouvant  6tre  utilises  sur  tout  aeronef. 

Son  objectif  est  de  proposer,  apres  validation,  des  proJets  de  standards  OTAN  (Stanags)  detinissant  une  j 

architecture  commune  et  ses  constituents  et  permettant  d'assurer  lour  interchangeabllite.  | 

L’accent  sera  mis  plus  particulierement  sur  le  coeur  des  systemes  avioniques  et  sur  les  CNI.  | 

Cependant,  le  programme  traltera  des  probiemes  associes  e  I'ensemble  des  senseurs  d'un  aeronef.  II  ! 

comprend  plusieurs  phases  ;  definition,  validation,  evolution.  f 

L’ASAAC  fait  I'objet  d’un  protocole  d’accord  signe  entre  les  ministeres  de  la  defense  de  la  RFA,  du  * 

Royaume  Uni  et  de  la  France  en  1990.  Les  Etats-Unis,  bien  qu’ayant  tres  activement  participe  au)  'ravaux 
de  preparation,  n’ont  pu  signer  e  cette  epoque  pour  des  raisons  budgetaires,  mais  doivent  le  faire  en  1991.  . 

En  signant  cel  accord,  les  ministeres  ont  reconnc  que  I’ASAAC  constitue  leur  axe  prioritaire  d’effort  en  ; 

matiere  de  standardisation  en  avionique.  Cela  va  conduire  e  reorienter  la  plupari  des  actions  nationales  ! 

mentionnees  ci-dessus  qui  ne  sont  pas  encore  lancees  vers  ce  programme  en  cooperation,  comme  par  i 

example  pour  la  France  les  developpements  A^  et  SIERA. 

i 

\ 

III-3  •  Application  de  I'avionlque  modulaire  k  un  avion  de  combat  europeen  ;  un 

example 

2il _ Qbieclifs 

L’application  des  concepts  de  I’avionlque  modulaire  e  un  aeronef  existant  pose  jn  certain  nombre 
de  probiemes  qu’il  convient  d’etudier.  En  effet,  dans  ce  cas,  il  faut  lenir  compte  des  contraintes  liees  au  fail 
que  certains  elements  sont  definIs  et  qu’il  n’est  pas  souhailable  ou  impossible  de  les  modifier.  C’est  k  cette 
condition  en  effet  que  i’on  pourra  se  prononcer  sur  la  faisabllite  de  mettre  en  oeuvre  ces  concepts,  k 
I’occasion  d’un  retrofit  k  mi-vie  par  example.  C’est  de  plus  un  moyen  de  mesurer  les  avantages  de 
I’avionlque  modulaire  par  rapport  k  des  architectures  classiques. 

Pour  6tudier  ces  probl6mes,  le  SITE  a  pass6  un  central  k  I’induslrie  frangaise  sur  I’application  de 
I'avionlque  modulaire  au  Rafale.  Cette  ^tude  a  9t9  r9alis9e  par  cinq  socibtes  a^ronautiques  majeures 
(Dassault  Aviation,  maftre  d’oeuvre,  Dassault  Elecironique,  Sextant  Avionique,  SAGEM  et  Thomson-CSF)  et 
s’est  termin9e  en  mai  1991. 

Les  objectifs  de  I’^tude  9laient : 

-  obtenir  les  bases  d’une  premidre  architecture  modulaire  pouvant  6tre  utilis6es  pour  la  suite  des 
dSveioppement  en  France  et  en  cooperation, 

-  recenser  les  caract9rlstiques  dimensionnant  le  systdme  d’arme, 

-  ^valuer  le  degrd  d’applicabilitd  des  principaux  concepts  k  un  avion  existant,  et  done  les 
contraintes  qui  en  decoulent, 

determiner  un  ensemble  de  ressources  modulaires  standardisables  avec  la  technologie  disponible 
aujourd’hul. 


Les  principr’Ies  contraintes  prises  en  compte  sont : 

-  la  definition  de  I’amenagement  des  soutes  k  equipements  et  les  volumes  alloues  k  I’avionlque, 

-  la  definition  des  servitudes  :  generation  eiectrique,  syst6me  de  refroidissement  et  de 
condilionnement, 

■  les  objectifs  de  securite  lies  aux  missions  basse  altitude  tous  temps  et  suivi  de  terrain. 

Les  fonctions  operationnelles  sont  celles  qui  sont  deje  definies  ou  prevues  pour  cet  avion, 
I’hypothese  de  base  etant  que  I’architecture  fonctionnelle  est  independante  de  I’organisation  materielle  su' 
laquelle  elle  est  projetee.  Le  but  de  I’etude  n’est  done  pas  de  valider  le  concept  en  general,  mais  de  proposer 
k  iso-fonctions  operationnelles  les  decompositions  modulaires  des  ressources  materielles  representatives 
de  I’architecture  du  systeme  (SNA  ;  Systeme  de  Navigation  et  d’Attaque)  et  d’en  deduire  les  avantages, 
inconvenients  et  contraintes. 


3-2  -Hypotheses 


Pour  determiner  le  cahier  des  charges  du  SNA,  on  s’appuie  sur  les  fonclions  op6ralionnelles  pO) 
qu'il  doit  rdaliser.  Dans  le  cadre  de  cette  etude,  it  a  ete  pris  en  compte  les  FO  principales  qui  influence 
directement  la  definition  du  systeme,  c'est  e  dire  ceiies  qui  perr.e'i*ent  de  le  dimensionner.  D'autres 
foncticns  poi.'.raient  etre  ajoutees,  mais  sans  induire  de  modifications  profondes  des  ressources 
materielles.  Les  FO  considerees  sont  les  suivantes  : 

-  Navigation 

Pilotage 

Localisation/recalages 

Approche 

Gestion  du  vol 

•  Communications  (modes  clair  et  brouilies) 

-  Identification 

-  Gestion  des  systemes  avions  (servitudes) 

•  Interface  Homme/Syst6me  (IMS) 

-  Gestion  des  pannes  et  des  alarmes 

-  Maintenance  en  ligne 

-  Preparation/restitution  de  mission 

•  Conduites  de  tir  Air/Air 

-  Conduites  de  tir  Air/Sol 

-  Vol  tr6s  basse  altitude  (TBA) 

-  Autoprotection 

-  Elaboration  de  la  situation  tactique 

Dans  le  syst6me  actuellement  d6fini,  ces  FO  sont  r6alis6es  par  des  ressources  materielles 
comprenant  29  equipements  et  3  bus  multiplexes  conformes  au  projet  de  Stanag  3910. 

II  faut  noter  que  les  Commandes  de  vol  eieclriques  n'enirent  pas  dans  le  cadre  de  cette  etude,  et  que 
les  ressources  liees  au  Systeme  d'autoprotection  (CME)  et  e  I’optronique  secteur  frontal  (FLIP)  ne  son!  pas 
priset  en  compte  etant  donne  le  faible  avancemeni  de  leur  definition  au  moment  de  I'etude. 


3-3  Methode 

L'avionique  modulaire  debouche  essentiellement  sur  des  notions  de  tolerance  aux  pannes  et  de 
reconfiguration  dynamique  des  fonctions.  Pour  cette  raison,  fapproche  classique  de  decomposition  en 
equipements,  puis  en  modules  eiementaires  (LRM  :  Line  Replaceable  Modules)  ne  peut  conduire  k  une 
optimisation  de  I'architecture  car  elle  ne  prend  pas  en  compte  toutes  les  possibilil6s  de  regroupement  et  de 
commonalite  des  traitements,  ni  de  standardisation. 

La  methode  suivie  est  de  type  top-down,  e  partir  des  r6sultats  de  I’analyse  fonctionnelle  du  SNA 
deje  realisee.  Les  fonctions  definies  ont  dans  un  premier  temps  ete  regroupdes  en  enlites  possedant  des 
caru-.teristiques  materielles  de  mSme  nature  :  les  Entites  Homogdnes. 

Cette  approche  permet  de  determiner  les  diff6renis  conslituants  eiementaires  susceptibles  de 
reniplir  une  fonction  particuliere  etroitement  liee  aux  caracteristiques  materielles  :  ce  sont  les  modules 
Materiel/Fonclion.iel  (M-M/F).  Par  example,  on  trouvera  : 

-  un  module  recepteur  multi-bandes  doni  la  fonction  est  la  reception  radio-frequence  multi- 

bandes, 

-  un  module  DSP  (Digital  signal  Processing)  dont  la  fonction  est  I’execution  d'un  ou  de  plusieurs 
algotithmes  de  traitement  numerique  du  signal, 

-  etc. 

A  ce  stade,  un  module  M/F  n’est  pas  un  LRM,  car  il  n'y  a  pas  encore  eu  recherche  de  commonalite 
conduisant  k  une  standardisation  mat6i'elle  des  modules.  De  plus,  un  M-M/F  peut  etre  compose  d'un  ou  de 
plusieurs  LRM,  Cette  decomposition  permet  de  ; 

-  Connaitre  les  differents  traitements  associes  k  cheque  M-M/F  et  identifier  leurs  specificites. 

-  Determiner  lesEntrees/Sorties  de  chacun  deux,  sur  le  plan  informationnel  (type,  flux, 
caracterisliques  des  information)  que  materielles  (type,  support,  codage,  frequence,  debit,  etc). 

-  Recenser  les  contraintcs  associees  k  chaque  M-M/F  (de  localisation  geographique  dans  I'avion, 
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temporelles  (datalion,  temps  de  rdponse,  synchronisation),,  de  suret6  de  fonctionnement,  de  confidentialit6 
(segregation  “noir/rouge).,  d’alimentation,  de  volume,  d'environnement,  etc). 

Quand  chaque  module  M/F  est  ainsi  detini,  il  est  possible  d'envisager  les  regroupements  selon 
certains  crit6res  comme 

•  la  surete  de  fonctionnement  (regroupement  dans  un  m§me  rack  de  modules  redondants  ou 
separation  de  deux  sous-ensembles  pour  eviter  qu’une  panne  simple  ne  rende  indisponib'e  la  totalite  d’une 
fonction), 

•  la  vulnerabilite  (separation  physique  do  sous-ensembles  pour  la  resistance  aux  impacts), 

-  la  difficulte  des  tSches  de  validation  et  d'integration  (qui  conduit  e  homogeneiser  des  functions 
d  un  meme  rack), 

-  la  minimisation  des  volumes  d’echanges  d'informations  (regroupement  des  modules  ayani  k 
s’echanger  un  grand  nombre  de  donnees), 

et  avec  des  contraintes  comme 

-  le  nombre  de  LRM  par  rack, 

-  le  nombre  de  racks  par  soute, 

-  la  disposition  et  I'installation  des  soutes, 

-  la  dissipation  maximale  d'un  rack, 

-  le  nombre  d'abonnes  sur  un  bus, 

-  la  distance  maximale  enlre  emetleur  et  recepteur  sur  un  bus, 

-  etc. 

Cette  approche  a  conduit  k  d6finir  7  Entit6s  Homog6nes,  comme  indiqu6  sur  la  figure  3  : 

EH1  :  COVE  el  moleurs  (non  6tudi6e  ici) 

EH2  :  Interface  Syst6mes  Avion  ISA 

EH3  :  CNI  (Communications,  Navigation,  Identification) 

EH4 :  Coeur  Sysl6me 

EH5  :  IMS  (Interface  Homme-Sysifeme) 

EH6  :  Interface  Sysl6me-Emports  ISE 

EH7  :  RCO  (Radar,  CME,  Optronique) 

La  figure  3  fait  apparaitre  la  notion  de  R6seau  de  Communication  Sysl6me  (RCS),  qui  permel 
I’intdgration  loiale  de  I'architeclure,  sans  pr6juger  de  sa  nature  exacle  :  il  est  compos6  de  plusieurs  sous- 
r^seaux. 


La  figure  4  monire  un  example  de  d6composilion  de  EH2  en  modules  M/F.  L’EH2  comprend  les 
sous-sysl6mes  allerrisseurs,  6le'''ique,  d6marrage,  condilionnemeni  et  carburant.  Le  contenu  des  M-M/F 
est  le  suivant  : 

-  Capteurs/aciuateurs 

lls  peuvent  §tre  des  robinets,  valves,  v6rins.  pompes,  jauges,  capteurs  de  lemp§rature, 
tachymfetres,  6lectro-valves,  conlacteurs.  Pour  la  distribution  6lectrique,,  ce  sont  essenliellemeni  des 
6l6menls  de  commutation  et  de  protection. 

-  Interfaces  capteurs/actuateurs 

Ce  module  realise  les  interfaces  6lectriques  de  tous  les  capteurs/actuateurs  pour  chaque  sous- 

systfeme. 

-  Concentrateur  signaux  capteurs-'acluateurs 

II  assure  la  concentration  de  tous  les  signaux  g^n^r^s  par  chaque  interface  pour  permettre  leur 
exploitation  par  le  module  de  gestion.  II  peut  dtre  r^alisd  sur  le(s)  m§me(s)  LRM  que  le  module  interface. 

-  Gestion  ressources 

il  constitue  ia  partie  inteiligente  de  chaque  sous-systeme.  II  execute  les  traitements  Ii6s  aux 
commandcs  et  aux  surveillances  des  circuits,  aux  diff^rentes  regulations,  k  la  synthese  des  pannes,  etc.  II 
presente  une  liaison  avec  le  RCS  pour  les  echanges  avec  d'autres  EH. 

Cette  EH  necessite  des  redundances  et  des  reconfigurations  au  niveau  des  traitements  de  commande 
et  de  gestion  pour  en  assurer  la  disponibilite  et  des  surveillances  et  consolidations,  etc,  pour  la  securiie. 

Les  autres  EH  sort  decomposees  comme  suit. 
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£ld2LfiLZ(CNI  et  RCO): 

Antennes 

Etage(s)  hyper-frequence  (analogique) 

Etage(s)  preprocesseur(s)  (numerique  et  conversion  A/N) 

Etage(s)  traltement  du  signal 
Traitements  et  gestion  de  la  ressource 

£tM(coeur  systeme) 

On  trouve  ici  un  seui  M-M/F,  qui  effectue  les  traitements  suivanls  : 

-  Gestion  technique 

initialisation 
maintenance  sol 
fusion  des  capteurs 

synthase  des  informations  (de  localisation,  situation  tactique,  pannes) 
gestion  des  ressources  (alimentations,  compatibilites,  capteurs,  armements) 

■  Conduite  de  la  mission 
cooperation 

conduite  du  vol  (elaboration  des  trajectoires  el  des  informations  de  pilotage) 
macro-fonclions  telles  que  les  conduites  de  tir,  les  contre-mesures,  la  gestion  du  vol 

-  Gestion  des  pannes  et  des  alarmes 

•  Gestion  systems 

•  Gestion  de  I'lHS 

synthese 

affectation  des  visualisations 
affectation  des  commandes 

•  Gestion  des  memoires  de  masse 

base  de  donnees  cartographique 

base  de  donnees  preparalion/reslilulion  do  mission 

logiciels  de  reconfiguration 


EHSflHS) 

Visualisations/Commandes 
Interface  video  et  Interface/concentrateur 
Generateur  de  trace/signal  et  InterprSteur  de  commandes 
Traitements  el  gestion  de  la  ressource  IMS 

aiSdSE) 

Les  interfaces  avec  les  emporls  soni  standardisees  selon  la  norme  MIL-STD-1760.  On  trouve  done 
des  fonctions  d'interface  et  de  distribution  realisees  par  un  module  d'interface  specifique  MIL-STD-1760 
Sloresl/0). 


3-4  Resultals 

3-4-1  Architecture  generate 

Sur  la  base  de  la  decomposition  fonctionnelle  precedente,  une  architecture  generate  a  ete  eiaboree. 
Elle  est  presentee  en  figure  5. 

Elle  represente  une  solution  intermediaire  pour  I'avionique  modulaire,  puisque  certains  sous- 
onso.mblcs  ns  sent  pas  entieremsnt  integres  :  RCO.  CNI  et  CDVE. 

Les  principales  caracteristiques  en  sent  les  suivantes. 

Notion  de  coeur  systeme 

L'architecture  repose  sur  le  coeur  systeme,  qui  gere  la  totaliie  de  I'avionique  e  i’aide  d’un 
ensemnic  de  ressources  techniques  (capteurs  et  IMS)  que  constituent  les  autres  EH. 

Definition  des  bus  globaux 

Les  rack  de  traitements  (ou  de  gestion)  sont  relies  enire  eux  par  un  bus  global.  Pour  eviter  des 
modes  de  panne  communs  lies  au  fait  que  I’interface  de  communication  de  ces  racks  sont  des  points  de 
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passage  obligatoires,  il  est  n^cessaire  de  disposer  de  deux  bus  globaux,  auxquels  sont  connect^s  toutes  les 
EH.  Ces  bus  sont  du  type  HSDB  ou  HSRB  et  sont  redondfis. 

Architecture  syst^me  sdcurisde 

La  prise  en  compte  de  ia  fonction  op4ralionneile  TBA  impose  une  architecture  de  type  double 
chatne  pour  d^montrer  le  niveau  de  sdcuritS  recherchd.  Ceia  renforce  la  n^cessitd  d'un  bus  global  double, 
avec  couplage  aux  deux  bus  des  capteurs  (radar,  radio-altimdtre,  base  de  donn^es  g^raphique)  ainsi  que 
du  coeur  syst6me  (qui  diabore  les  trajectoires)  et  des  COVE. 

Coeur  systdme  sdcurlsd 

L'diaboration  des  trajectoires  TBA  par  le  coeur  systems  impose  Id  aussi  d'en  sdcuriser  le 
fonctionnement.  On  est  done  amend  d  le  sdparer  en  deux  sous-ensembles  pour  assurer 

-  la  segregation  des  traitements  TBA 

-  une  moindre  vulnerabilite  physique 

•  la  consolidation  des  ordres  TBA. 

Cependant,  il  serait  possible  d'envisager  des  mdeanismes  de  sdeurisation  au  sein  d'un  mdme  rack, 
plus  faciles  d  mettre  en  oeuvre  dans  une  structure  modulaire  grdee  d  le  redundance  du  bus  de  fond  de  panier, 
et  la  possibilitd  de  dupliquer  et  de  sdgrdguer  des  traitements  sur  des  LRM  diffdrents. 

Notions  de  base  de  donndes  et  de  bus  serveur 

Certaines  fonctions  ndeessitent  des  volumes  importants  de  donndes  stockdes.  Les  utilisateurs  de  ces 
donndes  sont  multiples,  surtout  en  tenant  compte  des  besoins  de  reconfiguration  des  logiciels  en  cas  de  panne 
ou  selon  la  mission  ou  I'dtat  du  systdme.  Cela  conduit  d  proposer  un  lack  'case  de  donndes'  qui  concentre 
toutes  les  ressources  de  stockage  ndeessaires  et  permet  I'accds  de  toutes  les  EH. 

Le  volume  d'informations  transfdrd  pouvant  dtre  trds  important,  un  bus  serveur  d  haut  ddbit 
auquel  tous  les  utilisateurs  sont  abonnds  est  spdeifid  pour  dviter  de  pdnaliser  les  performances  des  autres 
dchanges  sur  le  bus  global.  Ce  bus  peut  dtre  du  mdme  type  que  le  bus  global  par  souci  de  standardisation 
(mais  un  bus  3910  est  suffisant  pour  le  Rafale). 

Notion  de  bus  capteur 

II  y  a  un  besoin  de  communication  entre  M-M/F  d’une  mdme  EH  (par  example  :  pour  I’lHS,  enire 
la  constitution  d'image  et  la  gdndration  de  tracd,  un  ddbit  de  40  Mbits/s  est  ndeessaire.  De  mdme  entre  le 
prdprocesseur  et  le  DSP  des  CNI  et  entre  I'Unild  Arithmdtique  et  le  PSP  (Programmable  Signal  Processor) 
du  radar,  avec  des  ddbils  de  100  Mbils/s).  Si  ces  fonctions  sont  dans  deux  racks  diffdrents,  il  faut  ddfinir 
un  bus  sdrie  (car  la  distance  entre  racks  peut  dtre  importante)  de  ddbit  100  Mbits/s  utilisd  en  poin  d 
point. 


Notion  de  bus  de  commande  et  de  contrdle  (bus  CC) 

L'analyse  des  ddcompositions  matdrielles  des  EH  montre  un  besoin  de  communication  d  bas  ddbit 
pour  la  transmission  de  commandes  et  la  saisie  d'informations  de  contrdle  (status).  C'est  le  cas  entre  les 
diverses  ressources  de  I'lHS  placdes  en  cabine  :  un  bus  de  type  1553B  convient,  mais  doit  dtre  doubld.  C'est 
aussi  le  cas  entre  diffdrents  LRM  des  ISA  et  ISE,  pour  lequei  le  couplage  d  un  bus  1553B  est 
surdimensionnd;  Id,  un  bus  de  type  RS422  doit  surfire. 

Intdgration  des  Centrales  Inertielles  (Ct)  aux  CDVE 

Les  ressources  des  Cl  sont  constitudes  de  deux  sous  ensembles  ;  le  senseur  et  son  diectronique  de 
contrdle  et  le  traitement  des  donndes  pour  obtenir  des  informations  inertielles  pures  et  de  I'inertie 
optimale.  L'hybridaticn  des  capteurs  inertiels  d  ceux  des  commandes  de  vol  permet  d'effectuer  une  synthdse 
des  informations  et  done  de  consolider  les  donndes  de  localisation.  Pour  cela,  le  sous-ensemble  senseur  des 
Cl  est  intdgrd  dans  les  CDVE. 


3-4-2  Ddcomposition  matdrielle 

Chaque  EH  fait  I'objet  d'une  ddcomposition  en  LRM.  Le  format  retenu  pour  les  modules  est  le 
Double  Europe  (I  dtude  d'implantation  a  aussi  dtd  effectude  avec  des  LRM  au  format  SEM  E,  mais  le  nombre 
de  modules  reste  le  mdme  et  les  volumes  des  soutes  ne  sont  pas  adaptds  d  ce  cas). 

Deux  types  de  racks  ont  dtd  ddfinis. 

Le  premier  peut  comprendre  un  ensemble  de  40  LRM.  II  peut  dtm  utilisd  pour  des  EH  comprenant 


un  grand  nombre  de  modules  d'Entr^es/Sorties  et  un  faible  nombre  d’interfaces  aux  bus  parall6les  de  fond 
de  panier.  Un  tel  bus  ne  pouvant  en  g6n4ral  relier  plus  de  IS  abonn^s,  cette  contrainte  a  conduit  d  dSfinir  un 
rack  de  18  LRM. 

Les  dimensions  du  rack  de  1 8  modules  sont ; 

Longueur  324,5  mm 

Largeur  220  mm 

Hauteur  273  mm 

Volume  19,5  litres 

Le  rack  de  40  LRM  est  d’un  volume  double. 

La  composition  et  la  liste  des  LRM  de  cheque  EH  est  pr§sent§e  ci-dessous.  II  apparait  des  modules 
mSmoire  qui  sont  lids  aux  mdcanismes  de  reconfiguration  et  de  gestion  dynamique  des  ressources.  De  tels 
modules  sont  aujourd'hui  proposes  avec  une  capacitd  de  4  Moctets,  qui  semble  suffisante  pour  la  plupart  des 
EH.  Dependant,  des  capacltd  deux  ou  quatre  fois  supdrieures  sont  envisageables. 

EH  ISA 

Cette  EH  comprend,  dans  un  rack  de  40  modules  ; 

-  un  ensemble  de  trailement,  effectuant  la  gestion  de  toutes  ses  fonctions.  Les  principes  de 
reconfiguration  offerts  par  I’archiiecture  modulaire  doivent  permetire  de  rdpondre  aux  besoins  de  sdcuritd 
et  de  fiabilitd, 

-  un  ensemble  d'F.ntrdes/Sorties.  La  structure  redondante  des  interfaces  est  implantde  sur  chaque 

LRM. 

Les  dchanges  d'informatlons  entre  ces  deux  ensembles  s’effectue  par  un  bus  CC  redondant.  Les  LRM 
de  I'ensemble  de  traitement  sont  relids  par  un  bus  de  fond  de  panier  paralldle,  de  type  PI-BUS. 

La  liste  des  modules  est  la  suivante  ; 


Ensemble 

Norn 

NombfS 

Traitement  UT  32  bits  RISC  2 

Mdmoire 

2 

Couplage  bus  global 

2 

Couplage  bus  CC 

2 

* 

Alimentation 

3 

Sous'Total 

1  1 

E/S 

Entrdes  discrdtes 

5 

Entrdes  analogiques 

3 

Sorties  discrdtes 

3 

Sorties  de  puissance 

2 

Entrdes  spdcifiques 

1 

Sorties  spdcifiques 

1 

Alimentation  capteurs/act. 

2 

SouS'Total 

1  7 

Total 

2  8 

Rdserve 

1  2 

EHISE 

La  composilion  est  semblable  d  cellc  do  I’lSA,  avec  des  couplages  suppidmentalres  a  des  bus  1553B 
(pour  I’lnlerface  emports)  et  serveur  (distribution  de  donndes  slockdes  aux  emports). 

La  liste  des  modules  est  la  suivante  ; 


Etiafimblfl  £1001  Nombre 

Traitement  UT  32  bits  RISC  2 

“  Mdmoire  2 

“  Couplage  bus  global  2 

“  CouplagebusCC  2 
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Sous-Total 

E/S 


Sous-Total 

Total 

Reserve 


EH  IMS 

II  comprend  : 

-  un  ensemble  de  traitemeni,  implant6  dans  un  rack  de  18  LRM,  relifes  par  un  PI-BUS.  II  est 
abonn^  au  bus  serveur  (cartoyraphie,.  etc). 

-  un  ensemble  de  fonclions  vid^o  et  interfaces  IHS  qui  realise  toute  la  g^nqration  de  trac6  et  la 
saisie  des  commandes.  II  est  r6alis6  dans  un  rack  de  40  LRM.  II  comprend  des  LRM  DSP  pour  le  trailemeni 
des  vid6os.  Le  bus  de  fond  de  panier  peut  Stre  du  type  PI-BUS,  mais  avec  un  d6bit  qui  peut  exc6der  les 
25Moctets/s.  II  est  relld  par  deux  bus  1553B  t  I'ensemble  des  termlnaux  de  visualisation  et  de  commande, 
avec  une  Wquence  de  fonclionnement  plus  6lev6e  (100  k  200Hz)  pour  diminuer  les  temps  de  r6ponse. 

La  decomposition  en  deux  ensembles  est  justifiee  par  le  fait  que  ieurs  mecanismes  de 
reconfiguration  sont  differents.  ils  sont  relies  par  un  bus  capteur  redondant. 

La  liste  des  modules  est  la  suivante  ; 

Ensemble  tJsm  Nombre 

Traitement  UT  32  bits  RISC  7 


Memoire 

3 

Couplage  bus  global 

2 

Couplage  bus  Capteur 

2 

Couplage  bus  serveur 

1 

“ 

Alimentation 

3 

Sous-Total 

1  8 

Video  et  E/S 

Couplage  bus  Capteur  2 

DSP 

2 

“ 

Generateur  de  trace 

5 

“ 

Traitement  video 

2 

“ 

Incrustation  type  1 

2 

Incrustation  type  2 

1 

Cartographie  numerique  n°  1 

1 

“ 

Cartographie  numerique  n"  2 

1 

Cartographie  numerique  n°  3 

1 

Generation  3D 

2 

“ 

Couplage  bus  CC 

2 

E/S  analogiques  audio 

2 

" 

Alimentation 

4 

Sous-Total 

2  7 

Total 

4  5 

Reserve 

1  3 

Couplage  bus  1553B  2 

Couplage  bus  serveur  1 

Alimentation  3 

Commutation  28V  9 

Commutation  200V  6 

Logique  securite  armaments  1 

Logique  securite  detresse  1 

Matrice  video  4 

Options  video  3 

Concentration  2 


1  4 


2  6 


4  0 
0 
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EHCNI 

Les  CNI  regroupent  les  fonolions  6l6mentaifes  suivantes  :  MIDS,  GPS,  IFF,  MLS,  V/UHF,  R/A, 
Centrales  inertielles  et  capteurs  ABC  (An6mo-Baro-Clinoni4triques).  Les  etudes  du  concept  6tanl  en  cours 
en  France,  une  decomposition  precise  n'a  pu  Stre  obtenue.  Les  estimations  realisees  e  partir  des  donnees 
disponibles  sur  ICNIA  (TRW),  qui  permel  de  couvrir  largement  les  besoins  du  Rafale  avec  70  LRM,  sur  le 
NAS  (RFA)  qui  correspond  k  une  configuration  proche  de  celle  du  Rafale  et  qui  comprend  123  LRM  de  26 
types  difterents,  conduisent  k  une  EH  CNI  composee  de  60  modules  dans  un  rack  ‘numerique''  et  trois  racks 
“hyper-frequence"  (  avec  une  reserve  de  12  LRM).  Un  rack  ayant  un  volume  de  19,5  litres,  I'hypolhese 
retenue  semble  conduire  k  un  surdimensionnement  par  rapport  A  I'objectif  de  I’etude  SIERA  (Thomson) 
d'un  volume  de  45  litres. 


mRCQ 

L’architecture  du  radar  etant  Ires  modulaire,  et  les  autres  sous-ensembles  de  cette  EH  n’ayant  pas 
ete  analyses,  la  liste  des  modules  retenus  pour  le  radar  est  celle  <i6\k  definie  :  83  modules  de  20  types 
difterents  (Ces  modules  sont  de  formats  divers,  ce  qui  rend  les  comparaisons  difficiles  avec  les  autres  EH). 
Le  fait  de  deporter  les  ressources  du  radar  apres  I’etage  de  traitement ;  signal  (PSP)  amOnerait  un  debit 
de  communication  Irds  important,  qui  pourrait  etre  realise  par  plusieuis  bus  capteurs  (de  I'ordre  de  5). 

Le  deport  du  PSP  n'esi  par  contre  pas  envisageable  actuellement. 


EHCaeur-Sysiema 

Elle  est  implantee  dans  deux  racks  identiques  de  18  LRM  et  comporte  ; 


NomtluLRM  NombfB 

UT  32  bits  RISC  5 

Memoire  3 

Couplage  bus  global  2 

Couplage  bus  seiveur  1 

Alimentation  3 

Total  1  4 

Reserve  4 


EHBasa.de.ttenn^ 


II  a  ete  suppose  que  la  moitie  du  rack  de  18  LRM  qui  la  compose  est  rkservke  k  la  base  de  donnees 
elle-meme  (qui  peui  etre  realisee  avec  des  lecteurs  de  disques  optiques  ou  des  memoires  silicium 
hybridees.  par  exemple).  La  decomposition  en  LRM  est  alors  ; 


Nom.duLRM 

UT  32  bits  RISC 
Memoire 

Couplage  bus  capteur 
Couplage  bus  ss.-vcur 
Alimentation 
Base  de  donnees 

Total 

Reserve 


Mojnto 

2 

2 

2 

1 

2 

9 


1  8 
0 


SyoMSfi 

On  arrive  pour  les  EH  etudiees  k  un  ensemble  de  21 0  LRM  reparlis  ainsi : 
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Car>acite  des  racks 

NbLBM 

Nb  fOseaB 

ISA 

40 

28 

1  2 

'SE 

40 

40 

0 

IHS 

58 

45 

1  3 

Coeur 

36 

28 

8 

Base  Donnees 

9 

9 

0 

CNI 

72 

60 

1  2 

Total 

255 

210 

4  5 

Hors  les  CNI  (60  modules),  les  ISO  modules  restants  sont  de  32  types  diflOrents,  ceux  les  plus 
utilises  Otant  ; 


UT  32  bits  RISC 
DSP 

MOmoire 

Couplage  bus  global 
Couplage  bus  CC 
Couplage  bus  serveur 
Couplage  bus  capteur 
Couplage  bus  1S53B 
Alimentation 


23 

2  (hors  radar) 
^  5 

1  0 
4 

5 

6 
4 

21 


Les  racks  ainsi  dSfinis  se  logeni  dans  les  scutes  ou  sent  actuellemcnt  installds  les  6qulpements 
qu’ils  remplacent. 

II  faut  noter  que  certaines  optimisations  ne  sont  pas  prises  en  compte  dans  ces  r^sultats,  comme 
par  example  pour  les  CNI,  ou  pour  les  bus  globaux  et  serveur,  qui  pourralent  §tre  identiques.  Les  rOsultats 
sont  done  pessimistes  par  rapport  k  coux  qui  devraient  gtre  obtenus  en  appliquant  totalement  les  concepts  de 
I'avionique  modulaire. 

Cette  Otude  ne  porte  pas  sur  I'ensemble  d'un  systdme  avionique.  Elle  montre  toulefois  qu'un 
syst6me  modulaire  permei  de  r6aiiser  les  fonctions  opOralionnelles  d'un  avion  de  taille  rOduite  comme  le 
Rafale,  tout  en  respectant  les  contraintes  de  sOcuritO  Ir6s  s§v6re  liOes  aux  missions  TBA.  II  n'apparait  pas 
de  gam  signlficatif  en  mati^re  de  volume  ou  masse  de  I'avionique,  mais  il  faut  considOrer  que  les  capacit^s 
de  reconfiguration  sont  largement  augment6es,  et  que  Ton  dispose  de  reserves  appr6ciables  (17  %  des 
ressources  installables). 


3-5  Conclusion 

Cette  6tude  repr6sente  un  premier  pas  vers  une  avionique  modulaire  en  France. 

Elle  a  permis  de  conforter  I'industrie  et  le  minist^re  dans  leur  foi  en  la  faisabilit^  de  ces 
nouveaux  concepts.  Elle  ne  permet  pas  actuellement  cependant  de  confirmer  tous  les  b^nSfices,  en 
particulier  financiers,  qui  en  sont  attendus. 

Elle  a  aussi  permis  d'identifier  des  probl6mes  techniques  compliqu6s,  comme  le  conditionnement 
ou  la  realisation  d'un  systems  d'exploitation  global  permettant  les  reconfigurations  automatiques  au  sein 
d'un  rack,  dont  la  maitrise  demandera  encore  beaucoup  d'effortc. 

La  poursuite  des  travaux,  pour  des  applications  futures,  sera  realises  principalement  au  titre  de 
programmes  en  cooperation  comme  ASAAC,  d6je  cite,  ou  EUCLID  (dont  le  domains  priorilaire  n°  4  a  pour 
objet  I'avionique  modulaire).  C'esi  necessaire,  d'une  pari  a  cause  des  sommes  requises  pour  mener  a  bien 
u.n  tcl  devGloppement  et  d'autre  part  pour  assurer  ia  staiiUaidisaiiun  la  plus  large  dans  I'OTAN,  qui  seule 
peut  amener  une  optimisation  de  I'utilisation  des  ressources  et  de  I'interoperabilite  au  sein  de  I'alliance. 


IV  -  LE  SOTWARE  BUS 

Le  chapitre  precedent  montre  une  utilisation  intensive  de  module  de  traitement  arithmetique  et 
logique  (UT)  au  sein  d  un  systeme.  Cela  reflate  I'importance  de  ce  type  de  traitement,  qui  se  traduit  par  des 
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volumes  de  logiciels  en  croissance  exponentielle.  Ces  UT  doivent  6tre  standardis^es,  avec  trois  buts 
principaux  : 

-  rinterchangeabilitd  physique,  qui  est  assurde  par  la  conformity  aux  spycifications  F3I, 

-  la  reconfiguration  dynamique,  qui  impose  qu’au  sein  d'un  mgme  systyme,  tous  les  moduies  UT 
puissent  fonctionner  avec  les  logiciels  implantys  en  mymoire  de  masse, 

-  la  portability  des  logicieis,  voire  des  modules  UT  eux-mymes,  d’un  systyme  y  I'autre. 

II  est  tentant  d'en  dyduire  la  nycessity  de  standardiser  un  code  d’ordre  unique  et  un  systyme 
d'exploitation  temps  ryel  unique. 

Dependant,  cette  voie  a  dyjy  yty  explorye  et  a  conduit  y  de  syvyres  dysagryments.  Le  oypartement  y 
le  oyfense  Amyricain  a  standardisy  un  code  d'ordre,  le  MtL-STD-1750A.  Or  les  unity  centrales  ryalisyes 
avec  ce  code  d'ordre,  a  16  bits,  ont  yty  rapidement  dypassyes  au  plan  des  performances  par  des  matyriels  32 
bits,  en  particulier  RISC  (Reduced  Instruction  Set  Computer),  avant  leur  mise  en  application  y  grande 
ychelle  en  ayronautique.  La  France  a  fait  ia  mSme  dure  expyrience  avec  le  programme  CMF  (Calculateur 
Militaire  Futur),  qui  bien  qu'ytant  basy  sur  un  code  d'ordre  32  oils,  n'a  pratiquement  pas  eu  d'application. 

La  standardisation  du  code  d'ordre  pour  toutes  les  piateformes  militaires  prysente  done  des 
inconvynients,  que  Ton  peut  lister  de  la  fagon  suivante  : 

-  elle  constitue  un  frein  y  I'innovation  technologique, 

-  elle  ne  permet  done  pas  d'utiliser  la  meilleure  technologie  disponible  y  un  moment  donny, 

-  elle  ne  permet  pas  de  profiter  de  la  synergie  avec  le  secleur  professionnel  civil,  qui  dans  ce 
domaine  bynyficie  d'un  dyveloppement  plus  rapide  que  le  secteur  militaire,  y  la  fois  au  plan  des  matyriels 
que  des  outils  logiciel, 

-  elle  implique  I'immobilisation  de  budgets  considyrables  pour  maintenir  y  niveau  les 
performances. 

On  pourrait  imaginer  d'utiliser  comme  standard  un  code  d’ordre  du  commerce.  Mais  ly  encore,  les 
mymes  inconvynients  surgissent,  car  tout  choix,  fut-il  bon  (ce  qui  est  difficile  y  pryvoir  y  moyen  terme), 
restraint  considyrablement  les  possibilitys. 

Une  solution  pour  sortir  de  cette  impasse  consiste  y  avoir  une  interface  standardisye  entre  to 
logiciei  d'application  et  le  systyme  exycutif  temps  ryel  (RTX)  :  e’est  la  notion  de  software  bus. 

Par  analogie,  on  peut  en  effet  discerner  trois  niveaux  de  standardisation  d’interfaces  ; 

-  celle  pour  les  ychanges  entre  sous-systymes,  ou  entre  racks,  par  I'utilisation  de  bus 
multiplexys  comme  le  HSDB, 

-  celle  pour  les  ychanges  entre  modules  d'un  rack,  par  I’utilisation  de  bus  de  fond  de  panier 
comme  le  PI-BUS, 

-  celle  entre  le  logiciel  opyrationel  d'un  module  el  son  exycutif, 

Le  but  est  d'obtenir  une  portability  totale  du  logiciel  opyralionnel  d'un  ensemble 
processeur/exycutif  a  I'autre,  en  acceptani  la  contrainte  d'une  recompilation  (les  modules  d’un  m6me  rack 
devront  done  avoir  un  niveau  supyrieur  de  standardisation,  pour  assurer  les  reconfigurations).  Cela  permet 
d'obtenir  : 

-  I’indypendance  vis  y  vis  du  matyriel, 

-  la  portability  des  applications, 

-  la  ryutilisability  du  logiciel. 

La  DEI  (Direction  de  i'Electronique  et  de  I’lnformatique)  de  la  DGA  a  lancy  des  ytudes  allant  dans  ce 
sens,  qui  comprennent  plusieurs  volets. 

Un  exycutif  temps  ryel  comprend  plusieurs  fonctionnalitys  ; 

-  la  gestion  des  interruptions, 

-  le  rendez-vous  Ada, 

■  des  primitives  asynchrones, 

-  la  gestion  des  E/S, 

-  la  distribution  (rypartition  sur  plusieurs  modules  de  ('exycutif  global,  en  particulier  pour 
satisfaire  les  objectifs  de  toiyrance  aux  pannes). 

Une  partie  de  ces  fonctionalitys  se  retrouvent  dans  le  Run  Time  Ada,  et  est  done  standardisye. 

En  ce  qui  concerne  la  distribution,  la  DEI  a  fait  dyvelopper  un  compiyment  d'exycutif,  appeiy 
EXTRA  (Extension  du  RunTime  Ada).  Les  cibles  sont  les  codes  d'ordre  MIPS,  SPARC,  680X0,  88000  el  I 
960,  avec  les  technologies  Ada  de  Verdix,  Telesoft  el  Alsys,  ce  qui  permet  de  couvrir  une  Irys  large  gamme 
de  produits. 

Pour  les  mycanismes  asynchrones,  Ada  n’offre  pas  de  services  tels  que  les  symaphores. 
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^vdnements,  etc,  bien  connus  dans  d'aulres  langages.  Cependant,  le  besoin  existe,  pour : 

-  prendre  en  compte  les  application  existantes  (portabllitd) 

-  permettre  les  communications  et  operation  de  signalisation  asynchrones, 

-  amSIiorer  les  performances, 

-  amdiiorer  la  portability  et  la  ryutilisation. 

Ces  services  yiant  extrSmement  couteux  en  temps  d’exycution  avec  le  myca^isme  du  rendez-vous, 
le  DEI  a  proposy  une  llste  de  primitives  pour  Insertion  dans  le  langage  Ada,  qui  constitue  un  modyie 
cohyrent  de  mycanismes  de  coopyration  asynchrones,  qui  permet  des  architectures  d'application  propres  et 
efficaces  en  yvltant  I'utilisation  de  solutions  non  protables.  Cela  doit  permettre  une  meilleure  adyquation  de 
ce  langage  aux  application  fortement  temps  rdel,  el  assurerait  une  portability  plus  facile  des  applications, 
ces  primitives  sont  : 

-  des  compteurs  :  “resource"  et  “buffer", 

•  des  ytats  :  “event"  et  “blackboard", 

-  des  Impulsions  ;  “pulses"  et  “broadcast'. 

Ils  sont  un  pryalable  y  la  notion  de  software  bus,  dont  les  ytudes  ne  font  que  commencer. 

En  ce  qui  concerne  le  software  bus,  il  existe  ly  encore  un  besoin  de  prendre  en  compte  les 
exigences  et  les  contraintes  de  tous  les  ulilisateurs  potentiels.  C'est  pourquol  cette  approche  doit  dtre  menee 
en  ccopyralion,  de  fagon  optimale  dans  le  cadre  des  programmes  inlernalionaux  d'avionique  modulaire. 


V  -  CONCLUSION  GENERALE 

Le  prysent  exposy  ne  prytend  pas  avoir  fail  le  tour  de  tous  les  probiymes  de  standardisation 
ayronau'ique  en  Europe  ;  le  champ  est  beaucoup  trop  vasle.  Mais  en  abordant  certains  secteurs  de 
I'avionique,  il  a  essayy  de  dymontrer  que  ; 

-  pour  le  futur,  la  standardisation  et  I’interopyrability  sont  des  enjeux  considyrables, 
opyrationnels  et  financiers,  En  ce  sens,  la  standardisation  est  y  elle  seule  un  besoin  nouveau,  qui  sera  de 
pius  en  plus  important, 

-  ces  enjeux  ne  pourront  Stre  gagnys  que  par  la  coopyration,  y  tous  les  niveaux. 
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MIXED  APPROACH  TOWARDS  MODULAR  AVIONICS 
CONFLICTING  REQUIREMENTS 
by 

J.P.  LACROIX 
THOMSON-CSF  RCM 
178  Boulevard  Gabriel  P6ri 
92240  MALAKOFF  FRANCE 


IMQDULAR  AVIONICS  CONFLICTING 
REQUIREMENTS 

1.1  INTRODUCTION 

New  avionics  development  efforts  like  PAVE- 
PILLAR  and  PAVE-PACE  in  the  USA,  EUCLID 


12LC.G.REQU1REMENTS 

LCC  requirements  reflect  customers  as  well  as 
airframe  manufacturers  expectations: 

-  to  lower  procurement  and  acquisition 
costs 

-  to  minimize  field  exploitation  costs 

Some  recognized  policies  seem  able  to  cope 
with  these  requirements: 

-  rely  on  standard  products  (F^i 
modules),  mass  produced  in  order  to 
share  the  NRE  costs  on  many  parts  and 
get  low  unit  prices;  but  tradeoffs  have  to 
be  made  on  the  number  of  suppliers,  so 
as  to  have  second  sources  without 
disseminating  the  production 


CEPA  4  in  Europe,  aim  at  architecture  selection 
or  standards  recommendations  ’n  oider  to  satisfy 
at  least  three  requirement  domains: 

-  LCC  (Life  Cycle  Cost)  requirements 

-  Performances  requirements 

-  Availability  requirements 


volume  on  too  much  companies, 

-  put  a  premium  on  reliability,  which 
depends  on  cooling  efficiency  among 
other  factors  like  components  quality 
level, 

-  skip  at  least  one  maintenance  level  by 
having  a  very  thorough  Built  In  Test  on 
each  LRM. 

These  policies  seem  obviously  able  to  offer 
benefits,  but  all  have  not  been  yet  demonstrated 
in  the  field. 

Nethertheless,  there  is  a  trend  in  new 
programs  to  put  a  high  priority  level  on  these 
problems  by  requesting  that  design  should  be 
ILS(lntegrated  Logistic  Support)-driven . 


PERFORMANCE  LEVEL 

NEW  CPUs/ARCHITECTURES 
IMPROVED  ALOORITHMS 
TECHNOLOGICAL  IMPROVEMENTS 
UPWARD  COMPATIBILITY 

LIFE  CYCLE  COST 
DECREASING 

ACQUISITION  COST 
DECREASING 


AVAILABILITY 

Figure  1.1:  MODULAR  AVIONiCS  REQUIREMENTS 
(Bnds  of  axis  stand  for  domains  to  be  optimized;  along  axis  are  some  means  allowing  to  achieve  that  goals) 


1.3  PERFORMANCES  REQUIREMENTS 

The  basic  idea  of  Modular  Integrated  Avionics 
is  to  concentrate  in  the  same  rack  many  CPUs 
previously  spreaded  in  severall  boxes  This 
computational  teaming  should,  at  a  given  time, 
deliver  a  sufficient  amount  of  processing  power 
while  benefitting  from  resources  sharing  and 
ottering  some  incremental  power  enhancement 
capabilities  {“graceful  upgrade"). 

But  progresses  have  been  made  since  the  era 
of  16  bits  processors,  and  new  32-bit  RISC  or 
CISC  processors  are  currently  able  to  replace  (on 
a  computation  capability  point  of  view)  severall  16- 
bit  CPUs  with  a  significant  cost  saving.  Graceful 
upgrade  (in  term  of  stress  effect  on  the  rest  of  the 
system),  could  be  achieved  by  relying  on 
technological  improvement,  assuming  use  of 
upward  compatible  micro-processors  (yet 


compatibility  requirements  could  be  a  progress 
limiting  factor). 

Nethertheless,  on  a  development/  production 
point  of  view,  having  less  CPUs  to  produce  could 
mean  to  add  more  NRE  anxjrtization  on  each  unit 
while  having  higher  unit  cost. 

1.4  AVAILABILITY  REQUIREMENTS 

Availability  requirements  are  due  to 
operational  people.  They  need  very  high  avionics 
availability  (current  figures  are  in  the  range  of  150 
working  hours  -  without  unpairing  failures)  and  the 
answer  comes  from  built-in  reliability,  fault-tolerant 
architecture  and  reconfiguration  capability  and 
that  will  be  the  drawback  which  could  hamper  this 
approach  with  cost  overhead  (typically  200  %  to 
300%). 


Method 

Hardware  penalty 

Latency  time 

Correction  time 

Reconfiguration 

delay 

Overhead  due  to 
spurious  errors 

Nbof 

faults 

DUPLEX 

100% 

Computation 

Cycle 

Computation  Cycle 

1 

TRIPLEX 

200% 

Computation 

Cycle 

Computation  Cycle 

2 

MAJORITY 

VOTING 

200  %  proc  and 
voting  circuits 

Instruction 

Cycle 

Instruction 

Instruction  Cycle 

2 

PARITY 

12%  memory 

Instruction 

Cycle 

Exception 

handling 

Not  Handled 

Exception  handling 

1 

ECO 

25  %  memory 

Instruction 

Cycle 

Clock  cycle 

Not  Handled 

Instruction  Cycle 

1 

MforN 

(M4f)  % 

Test  cycle 

Isolation+selftest 

Selftest+Loading 

Correction  time 

M 

Table  1.4  Fault  detection  policies 


1.5  INTERACTIQNS/CQNFLICTS  BETWEEN 
REQUIREMENTS 

They  are  mainly  in  the  field  of  the  architecture: 
everybody  will  agree  on  the  benefits  of  higher 
reliability  and  Built-In-Test  capabilities. 

But  the  rrwst  significant  parameter  is  the 
architecture  choice: 

Starting  from  performances  requirements, 
one  may  use  severall  identical  medium 
performance  CPUs  or  only  one  powerful  CPU 
able  to  do  the  job. 

In  the  first  case,  some  organization  schemes 
provide  fault  tolerance  and  reconfigurability  with  a 
low  price  penalty  (in  %  of  total  cost),  and  also 
graceful  upgrade  if  the  Real  Time  Executive  is 
able  to  offer  transparency  for  task  localization/ 
allocation;  but  latency  time  in  case  of  defect 


remains  questionnable  (see  Table  1  4). 
Nethertheless,  the  total  price  could  be  high,  due 
to  the  number  of  CPUs  used  which  does  not  offer 
a  good  cost  per  Mips,  even  if  a  great  number  of 
them  will  be  put  in  production.  High  reliability 
figures  are  also  difficult  to  achieve  in  such 
configurations. 

In  the  second  case,  using  only  one  CPU 
(obviously  based  on  one  unique  micro¬ 
processor)  cani  provide  fault-tolerance,  so  the 
architecture  has  to  be  designed  as  a  dual 
processor  one  or  better  as  a  triplex,  majority 
voting  architecture  (see  Table  1 .4).  In  this 
approach,  cost  overhead  is  high,  graceful 
upgrade  difficult  or  costly,  but  total  cost  could  be 
advantageous,  despite  there  is  obviously  less 
CPUs  to  produce. 

So  it's  difficult  to  find  the  best  (or  the  least  bad) 
compromise  at  a  given  time;  and  technological 
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progresses  are  also  char. '  •’  the  hypothesis 
every  two  years,  arxi  may  the  future  Avionics 
has  to  wait  for  the  multi-million  transistors  chips 
which  could  offer  parallel,  redundant  and  self 
reconfiguring/  repairing  architecture  at  an 
affordable  cost. 

The  greatest  risk  remains  to  overdesign  the 
modules,  because  the  aim  to  standardize  for  a 
wide  range  of  platforms  will  surely  lead  to  retain 
the  highest  level  of  performance/  environment 
requirements  in  every  domain,  and  that  could  not 
be  right  for  some  aircraft  retrofittir^  where  a  good 
balance  between  airframe  and  avionics 
capabilities  has  to  be  made. 

2JEQU1EMENT  MANUFACTURERS 
.CONSTRAINTS 

2.1  DESIGN  FOR  CUSTOMER'S  NEEP5 

On  an  industrial  point  of  view,  there  is  a  will  to 
design  for  a  right  adequacy  with  customer's 
needs  and  for  the  lowest  internal  production  cost. 
This  requirement  could  be  not  well  satisfied  by 
standard  products:  for  example,  at  the  CPU  side, 
it's  drfficult  to  get  the  correct  amount  of 
processing  power  needed  as  well  as  of  memory . 
This  problem  arises  also  for  I/O  processing  where 
dedicated  boards  are  often  to  be  designed  while 
some  standard  ones  are  under-utilized. 

So,  if  every  one  agrees  on  the  benefits  of 
building  prototypes  from  standard  (eventually 
under  utilized)  parts,  it  could  be  profitable  to  bring 
cost  effective  adjustements  for  mass  production. 

2.2  ROBUST  DESIGN  /  GRACEFUL 
UPGRADE 

Another  difficulty  of  the  designer's  job  is  to 
cope  with  short  technological  cycles:  standards 
need  currently  more  than  five  years  to  mature, 
while  technologies  change  every  two  years.  The 
dilemna  is  to  become  rapidly  obsolete  when 
using  stabilized  technologies  or  to  miss  deadlines 
when  using  too  emerging  technologies. 

So  there  Is  a  need  of  "robustness*  at  each 
level  of  the  system  (board,  chassis,  rack,  avionics 
suite)  in  order  to  accept  without  major  redesign 
some  technological  improvements  (related  to 
costs  savings  for  the  final  product)  as  well  as  to 
provide  growth  c^abilities  tor  evolution  of 
customer's  specifications  or  even  some  errors  in 
system  sizing  during  the  design  phase.  This 
need  is  currently  addressed  by  choosing 
upgradable  components  and  des'igning-in 
flexibility  through  programmable  devices. 

2.3  SHARED  DESIGN/  DEVELOPMENT 

There  Is  a  trend  for  design  and  development 
teaming  inside  companies,  between  companies 
in  a  country  and  also  between  countries: 

-  EUCLID,  PAH-2  and  EFA  programs  in 
Europe, 


-  International  cooperation  programs  like 
ASAAC,  Nun-Bennett  agreements. 

This  kind  of  business,  contractual  matters 
being  put  apart,  demands  a  very  accurate  Work 
Break-down  Structure  and  a  clear  system 
detinition  and  partitioning,  as  well  as  interface 
definition.  Tools  are  lacking  in  this  field,  and  a  part 
of  this  need  is  tentatively  addressed  by  the  tool 
described  in  the  later  part  of  this  paper. 

3  CANDIDATE  APPROACHES 

No  panacea  seems  able  to  solve  all  the 
depicted  problems,  and  a  combination  of 
methods,  tools,  tricks  is  currently  used. 

3.1  IMPLEMENTATION  INDEPENDANT 
DESIGN 

The  aim  of  this  approach  is  to  exercise 
methods  allowing  to  be  (almost)  free  of  the  final 
hardware  implementation. 

Such  methods  are  already  in  use  in  the  ASICs 
business:  Silicon  compilers  are  tools  which  offer 
some  protection  versus  process  change  or 
discontinuing  by  the  semi-conductors' 
manufacturers;  they  are  also  useful  for  doing 
request  for  quotation  and  price  comparison 
among  potential  suppliers. 

In  software  development.  In  order  to  try  to 
decrease  the  climbing  costs,  there  is  a  need  for 
modules  re-use;  Ada  and  (perhaps  more)  Object 
Oriented  Languages  should  provide  the  right 
answer . 

At  the  LRM  level,  it  seems  difficult  to  ask  for 
implementation  independance  if 
interchangeability  at  the  binary  level  is  requested; 
if  not,  one  may  argue  on  a  strict  conformance  to 
the  F^l  requirements  by  attaching  priorities  to 
requirements: 

-  Form  interchange  relies  to  mechanicai/ 
thermal  constraints  and  must  be  satisfied, 

-  Fit  interchange  could  be  understood  as  a 
top-and-bottom  conformance: 

*  at  the  top  by  compatibility  with  some 
HOL  (usually  software  written  in  Ma 
with  standardized  Real  Time 
Extensions), 

*  at  the  bottom  by  compatibility  with  a 
given  backplane:  connector,  pins 
allocation,  data  exchange  protocol, 

'  Function  interchange  should  be  achieved  for 
various  micro-processors  through  a  combination 
of  software  layers  and  hardware  additions 
(ASICs),  assuming  that  they  all  can  satisfy  to  a 
given  level  of  computational  capabilities  and 
response  time. 
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This  approach  could  offer  transparerKy  of  the 
inner  part  of  the  LRM  and  allow  to  use  for 
maintenance  purposes  CPUs  based  on  different 
micro-processors,  but  at  the  price  of  software 
recompilation  at  flight  line  depot,  and  less 
reconfiguration  capability  if  different  types  are 
used  within  the  reoonfigurable  entity  (usually  one 
rack). 


APPLICATION  (in  Ada) 


REAL-TIME  EXECUTIVE 


BOARD  SUPPORT 

ASICs 

CPU 

.^XtlARDWARE 

PACKAGE 

Figure  3.1  Hardware  encapsulation 
3.2  MIXED  APPROACH 
3.2.1  BOTTOM-UP 


3.2.1. 1  INTERACTIONS/LOCKS 
BETWEEN  STANDARDS 

One  of  the  first  conclusion  when  conducting  a 
bottom-up  approach  is  that  there  is  a  close 
relationship  between  potential  standards. 

For  the  hardware: 

-  Board  size  will  put  constraint  on  board 
density  (eventually  leading  to  a  two 
sided  board). 

-  Board  density  will  have  influence  on 
package  type. 

-  Package  type  will  have  influence  on 
cooling  management  (it's  difficult  to  use 
conduction-cooling  for  PGAs). 

-  If  surface  mounted  package  type  is 
choosed,  it  could  force  to  develop 
hybrids  or  ASICs. 

For  the  software: 

-  CPU  type  and  power  will  determine  if 
multi-processing  is  required. 

-  Communication  between  tasks  will  have 
influence  on  the  backplane  bus 
(message  onented  rather  than  memory 
oriented)  and  on  the  Real-Time  OS  (to 
be  tied  to  Ada). 

-  Bus  width  could  influence  the  hardware 
(connector  size). 


Technology  level 
ASICs 
Hybrids 


Package  type 
surface 
vs 

through 

hole 


Production  cost,. 


Figure  3.2.1. 1  Cross-coupling  of  standards 


f 


3.2.1. 2  CORE  FAMILY  BUILDING 

This  approach  aim  at  building  a  family  of  the 
four  main  types  of  LRMs  from  which  a  large  part  of 
any  avionics  suite  could  be  developped.  It  uses  a 
layered  method: 

-  1-st  layer  BUS  LEVEL  defines: 

‘  backplane  bus 


*  Test/  Maintenance  bus 

*  Down-loading/  Debug  bus  (if  dedicated 

bus  is  needed) 

-  2-nd  layer  INTELLIGENCE  LEVEL  defines: 

*  main  classes  of  micro-processors 

*  companion  ASICs  (if  any) 

*  service  serial  links 

*  bulk  memories 
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-  3-rd  layer  PERIPHERAL  LEVEL  defines: 

*  functionalities  requested  to  interface  with 
the  system  (Avionics  Bus,  AC/DC  I/O, 
Discrete  bits,..) 


Using  these  three  levels,  a  set  of  boards  can 
be  built,  some  with  or  without  intelligence  (Dumb 
I/O  or  I/O  controller,  Bulk  Memory  or  File  Sever),  all 
intelligent  boards  using  the  same  kernel. 

One  flexibility  advantage  was  to  place,  for 
some  families,  an  on  board  power  supply;  when 
considering  racks'  compos'rtion,  there  is  a  need 
for  a  redundant  power  supply,  which  should  have 


a  very  wide  range  of  delivered  power.  Adding  one 
LRM  could  force  to  add  two  PS  modules.  This 
problem  does  not  arise  with  local  on-board  power 
supplies,  which  offer  natural  incremental  power 
capabilities. 

This  method  is  applied  since  1980  in 
Thomson  for  680X0  based  designs,  targeting 
various  forni  factor  boards  (1/2  ATR,  Double- 
Europe,  ARINC  600, ...)  and  functionalities. 
Development  cost  and  time  savings  offered  by 
the  family  concept  are  a  major  argument  when 
answeririg  RFPs. 


Figure  3.2.1 .2  Layered  approach  of  LRMs  family 


3.2.1. 3  VIRTUAL  MODULE 

The  very  best  solution  is  to  have  tmly  F^l 
modules,  and  use  them  in  all  products,  but  in 
some  cases,  live  partial  revamping  of  old 
products,  it  could  be  useful  or  profitable  to  port 
designs  towards  other  board  sizes  or  different 
bacl^lane  bus,  or  to  add  functions  to  a  previous 
design. 

There  are  also  compromises  to  find  when 
looking  for  standards  acceptance  within  a 
company;  a  way  to  fight  the  well  known  NIH  (I^jot 
Invented  Mere)  position  is  to  leave  some  creativity 
to  people. 

The  'Virtual  module'  is  a  soft  way  to  do 
standardizaticn  because  it  remains  at  a 


conceptual  level:  the  standard  is  a  combination  of 
a  thoroughly  validated  schematic  together  with 
software  layers  (BSP,  BIT, ...).  This  Hardware/ 
Software  Kernel  could  be  considered  as  a  pail  of 
a  library  of  high  level  functions.  The  good  side  for 
users  is  that  they  get  some  freedom  of 
implementation;  the  good  side  for  standardization 
is  that  expensive  developments  which  insure 
software  portability  are  locked. 

This  ^roach  is  used  in  Thomson-CSF  for  a 
new  family  of  RISC  based  modules,  allowing  (non- 
predictive)  software  to  mn  on  any  cached  or  no- 
cached  architecture  developped  within  the 
company. 


OEOtCATCD  LAYOUT 
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Figure  4.1 .3  Virtual  Module  (or  SHAPE:  Software  hardware  Adaptable  Erocessing  Elements) 
_ Doni  try  to  soil  Virtual  Modules:  you  could  ba  paid  wHh  virtual  money  I _ 


3.2.2  TOP-DOWN 

When  building  an  Avionics  system,  and 
starting  from  operational  and  functional 
requirements,  the  problem  is  to  answer  at  least 
three  questions; 

-  were  are  the  functions? 

-  what  amount  of  resources  (memory,  I/O, 
computation  power,...)  do  they  need? 

-  which  is  the  volume  of  data  exchanged 
between  them? 

Misplacement  of  functions  could  lead  to 
avionic  bus  bottleneck  by  unuseful  data 
movements. 

Local  underestimate  of  processing  power 
coukJ  force  to  add  computation  capabilities  or  to 
use  remote  ones. 


Underestimate  of  data  traffic  could  lead  to 
increase  data  rate  or  to  add  busses  to  the  system. 

In  the  case  of  Integrated  Avionics,  the 
problem  is  widened  to  system  bus  aod  backplane 
bus;  and  also  because  this  concept  has  not  been 
yet  used  in  any  conflict,  and  vulnerability  issues 
are  not  known,  Top-Down  approaches  have  to 
handle  centralized  as  well  as  distributed  Avionics. 

Starting  from  some  knowledge  of  the  system, 
from  a  software  load  balancing  point  of  view,  the 
aim  is  to  find  the  best  repartition  of  processing 
power  among  different  racks  in  order  to  cope  with 
backplane  bus  bandwidth  and  system  bus 
capability:  the  ultimate  (technically  speaking)  goal 
should  to  be  able  to  place  tasks  anywhere  (CPU, 
Rack,  Avionics  Suite):  it  wouid  make  worksharing 
and  reconfiguration  easier. 


3.2.3  TOP-DOWN  METHOD 


It  was  decided  to  start  from  a  known  part  of  the 
RAFALE  aircraft  system.  Thomson-Csf  being 
main  contractor  for  the  Radar,  Counter- 
Measures,  Optronics  and  Communication 
equipments,  it  was  possible  to  get  all  needed 
informations  to  describe  the  equipments  and  do 
method  validation. 


The  first  step  was  to  build  a  common 
equipment  description  form,  then  design  cature 
tool,  simulation  method,  and,  if  needed,  the 
simulator. 

3.3  TOOL  DESCRIPTION 

3.3.1  DESIGN  OF  A  MODULAR  INTEGRATED 
AVIONICS  SYSTEM 


The  designer's  dreamed  CASE  Tool  could 
look  like  the  one  depicted  in  Figure  3  2  3. 


avionics  systems  (ratios  between  17  and  27),  but 
there  is  a  lack  of  methods  for  a  more  accurate 
system  sizing. 


One  of  the  candidate  architecture  for  future 
avionics  system  leads  to  place  in  the  same  rack/ 
chassis  severall  identical  modules  (CPU  or  I/O 
oriented)  which  were  previously  spreaded  among 
different  boxes. 


All  these  unknown  datas/  factors  make  uneasy 
the  design  of  an  efficient  (in  term  of 
requirements/  product  adequacy)  if  there  is  no 
help  available  through  some  Computer  Aided 
Tools. 


The  design  of  the  CPU  itself  is  not  a 
tremendous  task,  according  to  the  current  state- 
of-the-art  and  the  many  off-the-shelf  available 
micro-processors:  the  main  difficulties  to  solve  are 
in  the  field  of  the  behaviour  of  such  many  CPUs 
dealing  with  an  unique  backplane. 

By  the  time  this  study  was  launched,  there 
was  no  tool  allowing  to  forecast  the  bus 
efficiency/  load  in  an  not  well  known  context  of 
bus  accesses  scheduling;  tasks  scheduling 
inside  the  CPUs  must  be  aware  of  bus  activity, 
and  vice-versa. 


3.3.2  SYSTEM  SIMULATION 

The  simulation  of  any  avionics  system, 
w'-ether  centralized  or  distributed,  is  useful  to  the 
designer  to  get  a  rough  idea  of  how  the  data 
processing  parts  of  the  various  LRMs  are  acting. 

The  main  figures  of  interest  are  the 
scheduling  of  the  events  (hanvare  and  software), 
the  dynamic  bus  load  balancing  and  the 
resources  allocation/  sharing. 


The  second  unknown  factor  is  the  actual 
efficioncy  of  the  CPUs;  the  current  upgrade  in  the 
available  memory  space  and  the  computation 
power  leads  tu  a  TBD  shrink  of  resources. 

The  third  unknown  factor  is  the  initial  system 
sizing;  by  the  time  being,  some  laws  seem  to 
appear  between  successive  generations  of 
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3.4  PRELIMINARY  REQUIREMENTS  OF  THE 

loa 

3.4.1  TARGET  APPLICATION 

The  tool  Is  dedicated  to  the  simulation  of  a 
network  of  data  processing  racks,  in  respect  to 
the  internal  tasks  scheduling  and  the 
communication  between  data  processing 
modules.  The  activities  of  task  creation  and 
execution  are  to  be  simulated  with  their  timing 
aspects  In  mind,  as  well  as  wKh  their  hardware 
resources  consumption. 

The  tool  is  a  complementary  approach  in 
regard  of  some  commercialy  available  products 
which  are  more  suited  to  algorithms  simulation, 
network  simulation  and  to  global  systems 
simulation. 

A  particular  care  has  to  be  given  to  the 
modeiization  of  data  communication  between 
computation  modules  as  well  as  between  racks,  in 
the  future  attempt  to  find  the  best  place  of  these 
modules  in  the  most  suited  rack  of  an  Integrated 
Avionics  Suite. 

3.4.2  PROGRAMMING  ENVIRONMENT  AND 
HOST 

The  language(s)  for  the  programmation  of  the 
tool  must  be  supported  by  a  wide  range  of 
workstations:  the  perennity  of  the  tool  itself  is 
Insured  by  not  using  specific  or  exotic 
environment,  bound  to  any  non  standard 
workstation. 

3.4.3  MAN-MACHINE  INTERFACE  AND 
EASE  OF  USE 

The  tool  was  designed  for  people  being  not 
familiar  with  capture/  simulation  arcana,  in  order  to 
have  a  short  training  time. 

3.5  TOOL  DESIGN 

3.5.1  APPLICATION  FIELD 

The  tool  is  based  on  a  simplified,  macroscopic 
approach  considering  that  there  are  only  two 
useful  levels  in  an  avionic  system: 

•  the  computation  imdule  level 
-  the  global  system  level 

This  concept  allows  an  easier  relocation  of  the 
trxxlules  in  a  modular  avionic  system. 

The  analysis  of  the  software  side  of  the 
system  is  made  through  the  representation  of 
linked  software  modules:  there  are  three  types  of 
modules  and  four  types  of  links. 

The  description  is  done  in  an  hierarchical  way; 
for  example,  an  I/O  module  can  be  built  through  a 
combination  of  elementary  software  modules. 


3.5.2  SOFTWARE  ENVIRONMENT  AND 
HOSTS 

The  graphic  capture  and  simulation  package  is 
written  in  C.  It  should  be  easily  portable  on  any 
workstation  with  some  care  to  exercise  for  the 
graphic  library. 

The  very  first  release  of  the  tool  used  the 
SUNVIEW  graphic  library  developped  for  the  SUN 
™  workstations  but  the  design  was  rapidly 
ported  under  X  Window  (of  the  MIT)  with  the 
Xview  toolkit  offered  by  SUN:  this  toolkit  is  under 
port  on  DEC  stations  by  a  third  party  (Unipress). 

The  current  version  of  the  tool  is  fully 
operational  on  SUN  workstations  and  in  beta-test 
on  DEC  stations,  both  types  being  used  within 
the  author  facilities.  The  design  should  have  be 
made  with  the  Xlib  library  of  X  window  in  order  to 
run  on  any  X  Window  workstation,  unfortunately 
this  library  was  not  available  at  the  beginning  of 
the  study.  TBD 

3  5.3  USER  FRIENDLY  INTERFACE 

The  simulation  package  user's  interlace  relies 
on  pull-down  menus  and  multi-windowing  for  a 
higher  flexibility. 

The  capture  and  editing  of  the  modules 
(segments  and  links  description)  is  made  easy  by 
optional  "help  on  the  syntax"  placed  in  the  pull¬ 
down  menus. 

IS.  GRAPHIC  CAPTURE 

3  6.1  CAPABILITIES 

The  graphic  capture  utility  allows  the  system 
designer  to  descnbe  in  a  modular  way  the 
application  software  packages  running  on  severall 
computation  modules. 

3.6.2  METHODOLOGY 

As  said  in  §  3.5.1,  the  methodology  is  based 
on  three  types  of  software  modules  and  four 
types  of  links. 

Each  software  module  is  made  of  a  collection 
of  segments,  which  represents  an  execution  lime 
corresponding  to  instructions  cycles,  memory 
cycles  and  I/O  operations. 

Transactions  from  module  to  rrxidule  are 
executed  by  transfer  between  segments. 

3.6.3  TYPES  OF  MODULES 

3.6.3.1  Running  CPU  module 

This  module  is  made  of  a  serie  of  segments 
where  the  CPU  is  running  freely  and  does  not  rely 
nor  is  constrained  by  any  external  event. 
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3.6.3.2  Waiting  CPU  module 

This  module  represents  a  serie  of  segments 
where  the  CPU  is  denied  any  external  access 
cycle.  This  module  Is  used  to  describe  a  CPU  in  a 
passive  wait  state. 

3.6.3.3  Synchronization  module 

This  module  is  referenced  to  a  global  (in  a 
system  point  of  view)  event.  This  event  will 
synchronize  severall  CPUs;  it  is  issued  by  an 
unique  source,  but  may  be  received  by  more  than 
one  CPU. 

The  Syncronization  module  encompasses 
"active  wait*  segments  corresponding  (for 
exemple)  to  the  response  time  (delay)  of  an  I/O 
device. 

This  module  is  used  to  describe  a  CPU  in  an 
active  wait  state. 

3.6.3.4  Modules'  hierarchy 

The  tool  has  the  capability  to  represent  a  set 
of  modules  by  an  unique  rrwdule  (of  an  higher 
level).  The  graphic  capture  package  alows  such 
an  ascending  approach. 

The  reverse  approach  (descending)  is  also 
offered,  in  order  to  get  a  more  detailed  view 
inside  the  functionning  state  of  a  module. 

3  6.4  GRAPHIC  CAPTURE  CAPABILITIES 

The  graphic  capture  package  allows  the 
designer  to  open  simultaneously  severall  editing 
wirxtows.  Each  of  them  is  dedicated  to  the 
description  of  one  CPU  (block  diagram)  and  works 
on  one  hierach'ical  level.  Using  the  views  is 
orthogonal  to  the  combinations  CPU-Hierachical 
level. 

3.6.5  FILES  GENERATION 

3.6.5.1  Description  file 

The  graphic  capture  package  produces  a 
texte  file  containing  all  the  software  modules 
described.  This  text  file  is  correctable  and 
modifiable.  All  software  modules  are  referenced 
to  the  same  level,  but  they  remain  tied  to  a 
particular  GPU. 

3.6.5.2  Other  files 

The  package  generates  four  other  files; 

-  A  global  file  saves  all  CPUs  block 
diagrams  as  well  as  the  contents  of  the 
modules. 

•  An  utility  file  safeguards  the  memory 
space  allocated  to  the  CPUs  description 
and  the  graphic  context.  This  file  is 
useful  in  case  of  crash  of  the  capture 
package;  the  user  can  restart  from  a 
previous  stage,  preceding  the  crash. 


-  A  report  file  saves  all  error ,  warning  and 
help  messages. 

-  A  "help  to  debug"  file  records  the 
operator's  last  commands  (in  a  1024 
steps  moving  window);  this  file  is  helpful 
for  the  debugging  of  the  tool  itself,  by 
allowing  to  replay  the  commands 
producing  a  malfunctionning. 

3.6.5.3  Printer  output 

All  block  diagrams  of  the  CPUs  edited  on  any 
window  of  the  workstation  can  be  sent  to  a 
Postscript  printer. 

3,7  SIMULATOR 

3.7.1  POLICY 

Using  an  off  the  shelf  behavioural  simulator 
(VERILOG,  VHDL,...)  makes  mandatory  to  design 
a  source  code  generator.  Designing  this 
generator  proved  to  be  as  complex  and  difficult  as 
designing  a  discrete  events  simulator.  The  final 
choice  for  this  part  of  the  study  is  not  definitively 
made,  but  the  best  way  seems  to  look  for  a  discret 
even's  simulator. 

3.7.2  ENTRY  PARAMETERS 

The  description  of  the  software  modules  uses 
as  references  some  hardware  (in  the  sens  of 
performances)  parameters  of  the  CPUs  (p-- 
processors  cycle  time,  message  travelling 
delay,,..). 

All  these  parameters  are  entered  as  text  datas 
and  are  interactively  modifiable  during  the 
simulation. 

3  7,3  SIMULATION 

The  simulation  belongs  to  the  "discrete 
event"  type'  the  iikelyhood  of  apparition  of  an 
event  is  computed  for  each  previous  event. 

Between  each  event,  all  memory  accesses 
and  I/O  transactions  are  saved  for  each  CPU  for 
further  statiscal  analysis  purpose 

The  discrete  event  simulator  has  to  be 
compared  to  the  scheduled  simulator:  the 
previous  will  chain  the  events,  whatever  the  time 
between  two  succeding  events;  the  following  will 
exercise  its  scheduler  at  each  time  slot. 

3.7.4  SIMULATION  RESULTS 

The  simulation  output  is  a  graphic  one,  which 
represents  the  current  activity  of  each  CPU, 
expressed  as  segments  referenced  to  the 
software  module  which  contains  them. 

It  will  be  possible  to  appreciate  the  interactions 
between  CPUs  by  examining  the  activity 
diagrams.  The  statistical  analysis  of  resources  use 
should  be  offered  in  a  later  version  of  the  tool. 
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3.8  IMPROVEMENT  OF  THE  ACCURACY  OF 
THE  SIMULATION  (SYSTEM  LEVEL) 

3.8.1  WEAKNESSES  OF  THE  DESCRIBED 
TOOL 

For  the  available  version  of  the  tool,  all  CPUs 
are  executing  their  tasks  at  the  same  rythm, 
whatever  the  context. 

In  order  to  add  some  flexibility  in  the  tasks 
scheduling,  conditional  execution  of  the  software 
segments  has  to  be  provided. 

Another  problem  is  the  access  to  a  shared 
resource,  which  relies  on  priority  modelization 
and  resolving  mechanism. 

3.8  2  CONDITIONAL  EXECUTION 

The  first  improvement  will  be  to  launch  the 
execution  of  some  particular  segments  of  the 
software  modules  by  global  system  conditionning 
parameters.  These  parameters  will  be  either 
defined  by  the  user  when  setting  up  the  current 
simulation,  or  dynamically  generated  by  some 
software  modules  during  the  simulation.  The 
method  for  generating  these  global  conditionning 
parameteiS  is  not  yet  defined. 


3.8  3  ACCESS  PRIORITIZATION 

If  any  C  ^U  has  to  access  to  a  common,  shared 
resource,  the  synchronization  module,  which  is  in 
charge  of  this  request,  must  receive 
acknowledgement  or  denied  access  from  this 
resource:  the  pnority  access  mechanism  to  a 
shared  resource  is  yet  to  be  modelized 

4.  CONCLUSION 

The  described  tool  (graphic  capture  and 
simulation)  aims  to  bring  some  methodological 
help  for  designing  modular  integrated  avionics 
systems,  by  allowing  a  more  accurate  analysis  of 
their  dynamical  behaviour. 

The  refinement  of  the  system  modelization  is 
tightly  dependant  on  the  performance  of  the 
simulation  package.  Additional  work  will  be 
performed  during  the  current  year  in  this  area  and 
more  results  would  be  shown  at  the  lecture  time. 
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SUMMARY 

The  paper  reviews  the  critical  software-related  aspects 
where  thorough  planning  and  implementation  of 
philosophies  and  principles  are  needed,  in  order  to  be  able 
to  develop  software-based  avionic  systems  to  meet  target 
timescales  and  budgets;  identifies  some  of  the  critical 
software  technologies  that  will  facilitate  this  process,  both 
today  and  in  the  near  future;  and  briefly  deschbes  the 
implications  for  software  resulting  from  the  currently¬ 
emerging  modular  avionic  architeclures.  A  central  theme 
of  the  paper  is  that  the  system  and  software  generation 
process  should  be  placed  on  as  formal  a  theoretical  basis 
as  possible  This  is  in  order  to  be  able  to  deal  effectively 
with  the  complexity  of  the  software-based  avionic 
systems  that  are  'just  around  the  corner' 

1  INTRODUCTION 

1 . 1  The  magnitude  of  the  software  component  within 
military  avionic  systems  has  grown  considerably  over  the 
pas:  twenty  years  The  technology  has  come  a  long  way 
from  the  earliest  systems,  containing  some  16kbytes  of 
code  embedded  in  a  central  processor,  to  the 
architectures  under  consideration  today  that  feature 
many  megabytes  of  code  within  a  distributed  processing 
environment.  The  enormity  of  the  software  development 
task  has  required  a  move  away  from  the  assembler 
language  technology  of  the  early  years,  to  the  use  of 
standardised  high  level  languages  such  as  Ada,  in  order 
that  overall  Life  Cycle  Costs  may  be  minimised. 

Advances  in  semi-conductor  technology  over  the  same 
period  have  provided  the  system  designer  with  the 
microprocessor  and  memory  building  blocks  that  were 
unavailable  to  those  early  digital  systems.  Those 
components  have  the  performance  capability  to 
accommodate  the  code  expansion  common  to  most  high 
level  language  implementations.  The  software  content  of 
avionic  systems  seems  set  to  continue  increasing,  with 
the  next  generation  of  military  aircraft  likely  to  feature 
distributed  processing  architectures  based  upon  a 
modular  construction. 

1.2  In  parallel  with  this  growth  in  size  and  complexity, 
there  has  been  an  evolution  in  the  understanding  of  how 
these  systems  should  be  developed  in  order  to  meet 
performance,  cost  and  time-scale  targets.  The  rapidly 
increasing  capabilities  of  the  hardware  that  can  be  fitted 
into  an  aircraft  provides  more  and  more  scope  for 
software-based  functionality.  This  must  be  supported  by 
the  software  engineering  technology  to  handle  the 
definition  and  design  of  those  functions  within  reasonable 
costs  and  timescales. 

1 .3  A  central  theme  of  this  paper  is  that  we  need  now  to 
be  placing  the  system  and  software  generation  process 
on  as  formal  a  theoretical  basis  as  possible.  This  is  in 
order  to  be  able  to  deal  effectively  with  the  complexity  of 
the  software-bused  avionic  systems  that  are  'just  around 
the  corner*.  Formality  will  allow  automation  to  be  applied  to 
the  fullest  extent  in  the  development  process.  The  result 


IS  that  elficiency  of  the  generation  of  the  system  can  be 
maximised,  and  an  ability  is  provided  to  minimise  the 
number  of  errors  that  pass  through  to  the  later 
development  stages,  where  they  are  very  costly  to 
correct. 

1 .4  From  the  perspective  of  the  customer  for  these 
advanced  software-based  systems,  the  risks  associated 
with  the  software  content  of  projects  continue  to  grow,  as 
a  result  of  the  rapidly  increasing  complexity  that  is 
achievable  and  demanded  Large  real-time  embedded 
software  projects  are  prone  to  timescale  overruns  and 
budget  overspends,  or  fail  to  meet  their  operational 
requirements  The  result  is  increased  cost,  late  service 
entry,  a  need  tor  further  development  after  service  entry 
to  meet  original  requirements,  or  in  extreme  cases 
cancellation 

1 .5  This  paper  reviews  the  critical  aspects  where 
thorough  planning  and  implementation  of  philosphies  and 
principles  are  needed,  in  order  to  be  able  to  develop  these 
very  complex  systems  to  meet  target  timescales  and 
budgets;  identifies  some  of  the  critical  software 
technologies  that  will  facilitate  this  process,  both  today 
and  in  the  near  future,  and  briefly  describes  the 
implications  for  software  resulting  from  the  currently¬ 
emerging  modular  avionic  architectures 

1.6  This  work  has  been  carried  out  with  the  support  of  the 
Procurement  Executive  of  the  UK  Minist^  of  Defence 
(UKMoD(PE)).  The  views  expressed  in  this  paper  are 
those  of  the  author,  and  do  not  necessarily  represent 
those  of  the  UKMoD(PE). 

2.  THE  IMPORTANCE  OF  THE  LIFE  CYCLE 
MODEL 

2.1  Evolution  of  the  software  functionality  of  avionic 
systems  has  necessitated  a  parallel  evolution  in  the 
overall  approach  to  the  development  of  the  software 
component.  A  variety  of  idealised  lifecycle  models  for  the 
development  of  software  based  systems  currently  exist; 
lifecycle  being  defined  as  the  complete  process  from 
initial  definition  of  system  requirements,  through 
development,  production,  in-service  support,  to  eventual 
disposal. 

2.2  A  potential  difficulty  in  the  development  of  complex 
software-based  systems  is  the  conflict  between  the  need 
to  freeze  the  design  requirements  at  some  point,  in  order 
that  the  system  can  be  designed,  manufactured,  tested, 
etc,  and  the  reality  that  it  is  often  not  possible  to  define 
fully  the  requirements  for  the  deliverable  system  until 
experience  has  been  obtained  in  the  application  of 
something  that  represents  it.  To  this  end,  a  considerable 
proportion  of  the  overall  design/development  budget 
should  be  assigned  to  the  process  of  simulation, 
modelling,  prototyping,  animation  of  specifications,  etc 
prior  to  commitment  to  design;  furthermore,  as  much 
scops  as  possible  should  be  provided  to  allow  the 
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functional  requirements  of  the  system  to  be  further  refined 
throughout  the  development  programme. 

2  3  One  thing  IS  certain;  a  positive  decision  must  be 
made  from  the  outset  of  any  software  intensive  project,  as 
to  what  model  or  paradigm  is  to  be  applied,  in  order  to  set 
the  framework  ujxin  which  the  detailed  project 
development  process  is  built  (Paradigm  defined  as 
something  serving  as  an  example  or  model  of  how  things 
should  be  done) 

3  LIFECYCLE  MODEL  EVOLUTION 
3  1  The  Waterfall  Model 

3  1  1  The  conventional  modal  for  many  years  has  been 
the  internationally  known  'Waterfall'  Modal  (see  Fig  1 ). 

This  evolved  from  early  experiences  in  the  development  of 
software  based  systems.  II  was  formalised  in 
DOD-STD-2167  'Military  Standard  -  Defense  System 
Software  Development',  and  has  bean  carried  forward  into 
the  the  current  version  A  of  the  document’  issued  in  1988. 

3  1  2  The  Standard  requires  that  developers  implement  a 
process  of  managing  the  development  of  deliverable 
software.  A  sequence  of  phases  is  defined  tor  the 
definition  of  requirements,  the  design,  integration  and 
testing  of  software  in  parallel  with  tine  system  hardware 
development  process. 

3  1 .3  An  implication  of  the  Model  is  that  the  devetopment 
process  should  start  at  a  software  systems  highest  level 
of  functional  requirement.  Design  definition  proceeds 
progressively  Top-down'  through  a  successive  breaking 
down  into  lower  level  software  components,  down  to  the 
ultimate  component  level,  the  module.  The  coding  and 
integration  to  build  the  complete  system  is  then  carried 
out  'bottom-up',  allowing  full  testing  of  the  component 
software  assemblies  before  integration  into  the  next  level 
up 

3  1  4  The  DOD  (Department  Of  Defense)  Standard  also 
introduces  the  concept  of  baselines,  to  provide 
assistance  in  the  process  of  management  control  A 
baseline  represents  a  configuration  identification  at  a 
formally  specified  point  in  a  configuration  items'  lifecycle. 
The  completion  of  one  phase  of  the  development  process 
IS  determined  by  the  satisfactory  assessment  of  the 
deliverables  of  that  phase,  and  may  be  identified  as  a 
baseline.  The  products  of  the  next  phase  are  formally 
verified  against  the  previous  baseline,  as  part  of  the 
qualify  assessment,  before  themselves  being 
subsequently  incorporated  into  a  new  baseline. 

3.1  5  The  Model  has  come  in  for  some  criticism  over  the 
years,  as  it  is  conside.-ed  by  many  not  to  reflect  what 
actually  happens  during  the  lifecycle  of  software 
development.  The  concept  of  phasing  through  the 
development  process,  with  detailed  design  being 
completed  before  coding  and  test  being  carried  out,  and 
not  being  revisited,  does  not  match  what  has  to  realhr 
happen  in  a  project,  where  the  design  process  may  be 
reiterated  throughout  the  development  phase,  and 
probably  on  into  the  in-service  phase  as  wall, 

3.1.6  However,  I  would  suggest  that  the  basic  concept 
behind  the  Waterfall  Model  must  be  present  in  whatever,, 
more  refined  model,  is  employed.  The  fundamental 
requireme.nts  of  Top-down’  design  definition,  and  'bottom- 
up'  coding  and  integration,  are  essential  to  ensure  design 
traceability  in  the  final  delivered  product  However,  for  the 
complex  systems  of  today  and  the  future,  other 
processes  must  be  included  to  achieve  a  workable  life¬ 


cycle  model.  These  more  advanced  models  may  in  fact  be 
considered  as  further  elaborations  of  the  basic  concept 

3.1  7  It  is  vital  that  the  individual  system  developer  is 
given  the  freedom  to  arrive  at  the  final  product  by 
whatever  way  he  chooses,  provided  that  he  can 
demonstrate  from  the  outset  that  this  is  consistent  with 
the  basic  requirements  of  the  Waterfall  Model.  He  should 
have  the  scope  to  choose  the  development  life- 
cycle/methods  that  best  suit  his  organiS£.lion  and/or  the 
task  requirements 

3  2  V-Model 

3  2.1  A  development  of  the  model  appears  in  the  UK 
STARTS  Guide^  (See  Fig  2),  prepared  by  the  UK 
Department  of  Trade  and  Industiy  and  the  UK  National 
Computing  Centre.  The  STARTS  Initiative  (standing  for 
Software  lools  for  ^plication  to  large  Bsal  lime 
Systems)  provides  a  collation  of  information  on  available 
tools  and  techniques  for  the  development  of  software 
based  systems. 

3.2.2  The  V-Model  explicitly  introduces  links  between 
design  decomposition  phases  and  integration  and  test 
phases.  It  is  the  documentation  and  reviews  which 
provide  the  tangible  and  objective  milestones  throughout 
the  software  development  process.  Each  phase  can  only 
be  considered  complete  when  all  the  required 
documentation  has  been  completed  and  reviewed  to  have 
met  the  requirements  The  subsequent  phase  can  only  be 
started  when  all  the  input  documents  are  complete  and 
available 

3  3  Incremental  and  Evolutionary  Development 

3.3  1  The  incremental  approach  (see  Fig  3)  achieves  the 
final  full-function  deliverable,  by  building  the  total  system 
capability  in  ever  increasing  increments  Successive 
builds  have  increasing  capability,  which  is  formally 
demonstrated  at  pre-planned  points  in  the  programme.  Of 
partrcular  concern  in  this  process  is  the  co-ordinated, 
parallel  development  of  the  hardware  needed  to  support 
the  software  at  these  milestones 

3.3.2  The  evolutionary  approach  is  similar  to  the 
rncremental,  but  Instead  of  achieving  full  capability  over  a 
single  development  phase,  the  process  spreads  over  a 
number  of  phases,  probably  including  in-service  A 
limited-capability  system  is  taken  into  service  as  part  of  a 
pre-planned  programme,  which  sees  further  diJ’ielopment 
to  full  capability  in  parallel  with  the  initial  in-service  period. 

3  3  3  The  incremental  and  evolutionary  approaches  can 
help  to  reduce  the  risks  involved  in  single  phase 
development  to  full  functionality  of  very  complex 
systems  They  also  help  where  the  requirements  are 
Tuzzy'  I  e  where  the  general  requirements  are  known,  but 
the  details  are  lacking  The  building  of  a  limited 
functionality  system  allows  'hands-on'  experimentation  in 
a  real  or  simulated  scenario.  Increasing  understanding  of 
what  is  actually  required,  and  leading  to  refinement  of  the 
requirements. 

3.4  Models  for  Ihs  '90s  and  Beyond 

3  4.1  A  recent  proposal®  is  a  further  development  beyond 
the  incremental  approach.  Instead  of  a  rigid  number  of 
phases,  successive  levels  of  prototypes  are  used  (see 

4  2  1)  to  Iterate  towards  the  final  requirement.  The  use  of 
continuous  evaluation  and  risk  analysis  provides  a  good 
basis  on  which  to  make  necessary  decisions  over  options 
that  may  be  open.  When  the  prototype  has  iterated  to  the 
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point  where  it  meets  the  requirements,  it  is  engineered  as 
necessary  to  provide  the  design  soundness  required  by 
the  original  Waterfall  Model,  in  order  to  provide  the 
deliverable  product.  This  approach  is  known  as  the  Spiral 
Model  (tee  Fig  4). 

3  4.2  Another  possibility  is  the  Third  Generation'  Mode*, 
proposed  by  A  0  Ward^  of  BAe  (sea  Fig  5).  This  again 
recognises  the  importance  of  the  rapid  prototyping 
process  in  defining  the  requirements  for  the  eventual 
design  of  the  system. 

4.  THE  REQUIREMENTS  DEFINITION  PROCESS 

4.1  It  seems  dear  that  great  emphasis  will  be  placed  upon 
the  requirements  definition  process  in  future  models,  as  a 
result  of  the  present  difficulties  in  precise  definition  from 
the  eariy  stages  of  a  project.  It  is  here  that  the 
requirements  are  set  to  be  transformed  through  the 
development  process  into  the  final  design.  H  the  initial 
requirements  are  wrong,  then  so  will  be  the  system  and 
software  that  appears  at  the  end  of  the  devefopment 
process  If  we  can  only  describe  precisely  what  it  is  that 
we  want,  in  complete  and  consistent  detail,  then  the 
process  of  developing  it,  whilst  by  no  means  being  trivial, 
does  become  a  realistic,  relatively  low  risk  task  A  further 
complication  is  the  design  of  the  hardware  on  which  the 
software  wili  run.  which  often  has  to  be  tackled  from  an 
early  stage  in  (he  development  process  (see  Fig  6), 
because  of  the  long  lead  times  involved  in  obtaining  the 
components,  designing  enciosures,  environmental  testing 
leading  to  qualification  lor  the  application,  etc. 

4  2  Tachniques  and  Tools 

Techniques  and  tools  available  to  assist  in  the 
requirements  definition  process  include. 

4  2.1  Rapid  Prototyping 

Enables  the  system  developer  to  assess  design  and 
specification  decisions  through  the  implementing  of  part 
or  all  of  the  system,  without  consideration  of  integrity  and 
formality  requirements.  The  rapid  prototype  can  then  be 
exercised  in  realistic  situations. 

4.2.2  Animation 

I  Animation  of  a  systems  requirement  specification  is  a 
process  which  facilitates  the  examination  and 
demonstration  of  the  specification.  The  specification  is 
convened  into  an  operating,  visible  representatio.n,  which 
can  then  be  exercised  by  the  customer  or  designer  with 
the  aim  of  checking  that  the  specification  does  actually 
record  what  is  required 

II.  Rapid  prototyping  and  animation  may  be  applied 
Iteratively,  with  repeated  modification  to  the  models  or 
specifications  generated,  until  a  satisfactory  solution  has 
been  demonstrated.  In  tho  case  of  rapid  prototyping, 
there  is  also  the  option  for  the  prototype  to  be  developed 
funher  into  the  deliverable  product. 

4.2.3  Notatlonal  Tools 

Notational  tools  provide  support  to  the  process  of 
detailing  the  requirements  A  number  of  such  tools  now 
exist  in  proven  forms,  but  are  likely  to  need  further 
development  if  they  are  to  support  adequately  the  very 
complex  systems  now  being  considered.  In  particular, 
mathematical  formality  needs  to  be  introduced  as  far  as 
possible,  in  order  to  facilitate  automation  of  the  process. 


4.2.4  Analysis  Tools 

Automated  tools  are  required  to  detect  mis-specilications 
and  errors  during  the  early  stages  of  the  specification 
process. 

5  THE  EVOLUTION  OF  ADA 

5.1  Ada  today 

Ada  was  originally  developed  by  the  US  DOD  to  provide  a 
standard  language  for  the  development  and  maintenance 
of  large  real-time  embedded  systems.  The  language  was 
initially  standardised  as  MIL-STD-1815®  in  1980,  and 
subsequently  revised  as  ANSI-MIL-STD-1815A^  in  1983. 
The  tools  to  support  the  development  of  systems  with  the 
language  have  progressively  become  more  capable,  and 
more  widely  available  for  application  on  a  broad  range  of 
development  hosts  As  at  February  1991  there  was  a  total 
of  135  validated  compilers^  for  use  with  the  Ada  language, 
covering  a  broad  range  of  both  host  and  target  machines. 
A  number  of  these  compilers  are  second  or  third 
generation  developments,  and  the  efficiency  of  target 
code  produced  is  believed  to  be  becoming  very  good 
indeed.  A  wide  range  of  other  development  tools  are  also 
available  to  support  the  development  of  Ada  based 
systems.  A  significant  amount  of  demonstration  and 
development  has  taken  place  lor  real  avionic  applications, 
including  applications  having  flight  safety  implications. 
Offsetting  any  increase  in  code  required  to  carry  out  a 
particular  function  is  the  increase  in  the  caoabiiit'es  of 
target  processors;  there  seems  to  be  very  little  reason 
today  to  oppose  the  use  of  Ada  for  the  development  of 
systems  on  grounds  of  performance  alone,  for  a  broad 
range  of  avionic  system  functions 

5.2  Ada  9x  and  the  future 

5  2.1  Since  the  Ada  83  Standard  was  issued,  there  has 
been  a  considerable  progression  in  the  capabiiities  of 
computing  sysiems  appropriate  to  military  applications. 
There  has  also  been  a  realisation  from  practical 
experience  that  there  were  a  number  of  aspects  of  the 
original  Standard  that  were  less  than  perfect.  As  a  result 
of  these  factors,  the  Ada  9x  project  was  started,  with  the 
intention  of  defining  an  updated  Standard  for  applications 
in  the  '90s  and  beyond.  The  project  was  initiated  in 
October  1988,  with  an  invitation  to  the  public  to  submit 
revision  requests,  and  over  750  were  subsequently 
received.  A  number  of  meetings  and  vrorkshops  were  also 
initiated,  to  assist  in  the  process  of  further  refining  and 
prioritising  user  needs 

5.2.2  The  Requirements  Definition  Phase  was  completed 
in  December  1990,  with  the  publication  of  the  Ada  9x 
Requirements  Document®.  It  appears  that  there  is  still 
some  way  to  go  to  the  publication  of  the  updated 
Standard,  and  that  it  will  also  be  some  time  after  that 
before  the  development  tools  are  available  In  order  (hat 
the  Ada  9x  Standard  can  be  applied  in  real  projects. 

5.2.3  The  overall  goal  has  been  to  balance  the  necessary 
changes  for  the  languages'  growth  in  terms  of  applications 
in  the  1990s,  with  the  need  for  stabii'ty  in  terms  of 
presen/ing  the  integrity  of  existing  Ada  software  and 
fools.  Thus,  upward  corn^tibiiity  has  been  a  guideline 
(but  not  a  rule)  for  the  activity;  legal  Ada  33  programs 
should  in  general  be  legal  Ada  9x  programs,  and  should 
retain  the  same  functional  characterist'ics.  There  are 
exceptions  to  this  guideline,  and  it  wiil  be  interesting  to 
see  how  much  upward  compatibility  Ada  9x  eventually 
allows. 
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5.2  4  Upward  compatibility  is  likely  to  be  of  significance  m 
avionic  applications,  where  large  amounts  of  specialist 
software  are  required,  often  performing  safety-related 
real-time  functions.  Upward  compatibility  should  allow 
significant  amounts  of  software  to  be  carried  forward  from 
one  project  to  the  next;  lack  of  it  would  require  redesign 
and  comprehensive  reverification  at  the  changeover  from 
Ada  83  to  Ada  9x,  imposing  a  considerable  cost  burden  on 
that  development  project. 

5.2  5  At  a  more  detailed  level,  there  are  several  aspects 
identified  in  the  Requirements  Document  that  will  be  of 
particular  significance  to  the  avionic  field: 

I  The  need  for  the  Ada  9x  solution  to  accomodate  both 
parallel  and  distributed  process.ng 

II.  Support  for  modern  programming  paradigms 

Ml  Provision  of  facilities  to  support  real-time  appl'cations 

IV  Requirements  for  safety-critical  applications 

6.  AUTOMATED  TOOLS,  AND  THE  INTEGRATED 
PROJECT  SUPPORT  ENVIRONMENT 

6  1  Automated  Tools 

Automated,  integrated  software  tools  are  vital  to  the 
achievement  of  the  increased  software  productivity 
needed  to  match  the  rapidly  increasing  size  and 
complexity  of  software-based  avionic  systems 
Estimates  today  of  realised  productivity  in  the  production 
of  software  for  avionic  systems  vary  in  the  range  1000- 
3000  lines  of  fully-tested  coda  per  man  year  In  the 
future,  the  total  software  load  for  an  aircraft  may  amount 
to  more  than  the  equivalent  of  40-i.  million  lines  of  source 
code.  Maximum  productivity  will  be  essential  in  c"ler  to 
contain  development  and  support  costs,  and  will  need  to 
be  greatly  improved  over  that  typically  achieved  today  if 
the  systems  are  to  be  remain  affordable.  An  objective 
should  be  tftat  each  stage  of  the  lifecycle  is  suppoiled  by 
a  fully  automated  tool 

6.2  The  Integrated  Project  Support 
Environment 

6  2  1  As  the  complexity  of  avionic  systems  and  their 
softv/are  increases,  so  there  is  a  need  for  their 
development  to  be  suppoited  by  more  sophisticated  tools 
As  the  total  amount  of  software  content  increases,  so  the 
number  of  people  who  nued  to  access  these  tools  and  the 
design  itself  increases,  as  does  the  required  productivity 
of  the  software  development  process  Hence,  the  need 
for  these  tools  to  be  interfaced  together,  and  supported 
by  a  system  which  allows  access  by  a  number  of  people  at 
the  same  time  The  picture  is  further  complicated  by  the 
needs  of  international  collaboration  on  development 
projects,  loading  to  a  possible  need  lor  access  to  be 
spread  over  a  wide  geographical  area  The  Integrated 
Project  Support  Environment  (IPSE)  is  the  ultimate  goal, 
featuring  an  integrated  set  of  tools  providing  complete 
support  for  the  design/development  process,  through  the 
in-service  phase  as  well  as  during  initial  development  (see 
Fig  7). 

6.2.2  Integration  comes  in  two  forms;  inforiiiation  sharing 
between  development  tools  for  analysis,  specification, 
design,  coding,  testing  and  integration;  and  information 
management  via  con(igura*'on  control,  change  control, 
requir- merits  traceability,  and  prn,iect  management 
supfxtrt 


6.2.3  With  the  current  generation  of  avionic  system,  the 
Support  Environment  needs  to  feature  a  wide  range  of 
tools,  each  phase  of  the  life-cycle  being  supported  by  an 
automated  tool.  Each  tool  has  the  facility  to  interface  with 
others  within  the  integrated  toolset,  supported  by  a 
common  data-base  recording  the  design  itself,  its 
configuration  and  so  on. 

6  2.4  For  the  future  generation  of  system,  more  advanced 
tools,  and  more  of  them  will  be  required,  with  perhaps  the 
facility  to  tackle  safety-critical  as  well  as  mission-critical 
software.  A  highly  complex,  integrated  toolset  featuring  a 
common  database  and  user  interface  will  be  necessary, 
as  will  be  the  ability  to  provide  very  wide  distributed 
access 

6  2.5  Major  improvements  to  over  ill  productivities  ar  i 
required,  perhaps  by  a  factor  of  twe  or  more.  This  is  likely 
to  prove  very  demanding  on  the  tool  suppliers,  but 
software  p,'oductivity  is  an  area  where  such  improvements 
are  needed  if  we  are  to  assure  tliat  the  costs  of 
developing  systems  for  future  ap.nlications  are  kept  within 
acceptable  limits. 

7.  FORMAL  MATHEMATICAL  METHODS 

7  1  As  systems  complexity  increases,  it  becomes  ever 
more  apparent  ttiat  it  is  impossible  to  dynamically  test 
large  programs  to  ensure  their  correctness.  To  obviate 
this  proble','.,  we  need  to  unsure  that  ttie  program  is 
correctly  designed  in  the  first  place,  and  one  of  the 
techniques  promising  to  assist  in  the  achievement  of  this 
IS  the  formal  mathematical  specification  of  the 
requirements  for  the  software.  This  may  appear  at  first  to 
considerably  increase  the  effort  required  to  produce  the 
specification  Recent  experiences  however  indicate  that 
in  certain  circumstances  this  may  be  more  than  recovered 
in  the  reduction  of  time  and  costs  associated  with  the  later 
stages  of  coding,  integration  and  test,  as  a  result  of  a 
considerable  reduction  in  the  number  of  errors  oarried 
fonward.  The  specification  may  be  fo-mally  proven,  and 
reliably  demon  .mated  against  the  system  requirement  by 
means  of  automated  animation  techniq'  es 

7  2.1  The  title  'Formal  Method’  is  commonly  used  to 
describe  a  number  of  aspects  of  the  same  idea.  The  more 
correct  title  is  'Formal  Mathematical  Method'.  The  three 
fundame.ital  features  of  a  Formal  Method  are. 

A  m.athematically  formal  notation 

A  mathematically  formal  development  process 

A  mathematically  formal  means  of  proof 

7.2  2  TIte  mathematically  formal  notation  allows  the 
unambiguous  statement  of  software  specificalions;  these 
may  then  be  transformed  by  a  mathematically  formal 
development  process  into  programming  languages;  those 
transformations  may  then  be  proven  to  be  mathematica'ly 
correct  via  .ne  formal  means  of  proof 

7.2  3  The  following  example  illustrates  how  a  Formal 
Method  could  be  applied  in  a  practical  project. 

I  The  User  Requirement  for  the  system  is  first  set  down. 
Tfiis  would  often  be  expressed  in  an  informal  (i.e  not 
mathematically  precise)  way,  often  using  conventional 
language  such  as  engli'sh.  Because  of  the  lack  of 
precision  in  an;  commonly  used  language,  the 
Requirement  will  certainly  have  many  inconsistencies, 
errors  and  omissions,  even  if  the  drafter  managed  to  set 
down  a  correct  statement  of  what  he  thought  was  needed 
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(i.e  there  were  no  errors  in  the  record  of  what  he  wanted, 
based  upon  his  understanding  of  the  words  he  used), 
there  is  still  a  certainty  that  his  understanding  of  the 
words  and  the  use  of  words  would  not  be  precisely  the 
same  as  someone  else  reading  and  interpreting  the 
specification. 

II  The  User  Requirement  is  translated  into  a  Formal 
Specification  This  is  a  mathematical  object,  and  it  can  be 
precisely  shown  that  properties  hold  in  this  specification 
The  properties  ot  this  document  can  be  compared  wNh  the 
desired  behaviour,  as  part  of  the  process  of  verifying  that 
the  properties  do  exist  correctly  in  the  specification. 

This  comparison  may  also  be  used  to  refine  further 
understanding  of  what  properties  are  actually  required, 
leading  to  modification  of  both  the  User  Requirement  and 
the  Formal  Specification  With  some  specifications  an 
animation  process  may  be  applied,  where  the  spec  is 
'brought  to  life'  via  a  simulation  process,  su^h  that  the 
behaviour  of  the  system  described  in  the  specification 
can  be  physically  examined  and  exercised  This  then 
allows  Iterations  to  take  place,  drawing  out  what  the  user 
really  wants  from  what  he  originally  said  he  wanted 

III.  The  verified  Formal  Specification  may  then  be  refined 
into  a  more  detailed,  lower  level  specmcation  This  may 
be  repeated  a  number  of  times,  specifying  successively 
lower  levels  of  detail,  which  is  then  verified  and 
documented  The  process  is  ideally  repeated  until  the 
lowest-lp.el  specifications  can  be  the  subject  of  direct 
translation,  item  for  item,  into  programming  language 
statements  At  each  successive  stage  of  the  refinement 
process,  the  output  is  recorded  in  a  mathematically 
precise  and  proveable  form 

7.2.4  There  are  currently  serious  limitations  to  the 
applica'ion  of  Formal  Methods.  They  do  not  address 
considerations  such  as  timing  or  accuracy,  and  are 
currently  only  practicable  for  relatively  small  systems  (ot 
the  order  of  1 0-50,000  lines  of  source  code)  There  has 
been  little  real  standardisation  so  far  m  terms  ot  language 
constructions,  languages  such  as  Z  and  VDM  stil'  to  some 
extent  being  in  the  research  field.  The  methods  are 
oifficult  to  u.nderstand,  and  there  is  consequently  a 
difficulty  with  validation.  Tool  support  is  still  in  its  infancy. 
However,  further  development  of  tools  into  really  practical 
engineering  standards  seems  likely,  as  a  lesult  of  moves 
in  both  the  UK  and  internationally  to  encourage  their  use 
at  least  for  safety  critical  softwa'e.  The  fundamental  logic 
that  the  computer,  a  mathumati  .al  machine,  should  be 
programmed  using  mathenijiically  traceable  and 
proveable  techniques  cannot  be  ensily  dismissed.  There 
is  still  some  way  to  go  before  they  will  be  a  practical  tool 
for  the  sort  of  avionic  systems  under  consideration  today,, 
but  there  seems  a  strong  possibility  that  they  will  be  seen 
as  essential  sooner  or  later  Even  if  the  full  applicatiori  of 
formal  methods  to  large  systems  is  still  some  way  off, 
there  are  still  considerable  benefits  to  be  had  from  the 
application  of  a  notation  alone 

8.  AUTOMATED  STATIC  CODE  ANALYSIS 

8  1  Static  Code  Analysis  is  defined  as  the  process  of 
examining  the  behaviour  of  software  without  running  the 
software  on  a  computer  It  seems  likely  that  it  will  have  an 
important  role  to  play  in  the  near  future  in  the  cost 
effective  development  of  software,  as  part  of  the  process 
of  'design-right'  rather  than  lest-right'.  The  tools  currently 
available  wero  originally  devetoped  for  use  in  the  fields  of 
secure  and  safety  critical  software,  but  a''e  inherently 
suited  to  any  application  where  the  development  of 
correct  software  is  a  necessity.  Much  work  has  been 


carried  out  in  recent  years  in  the  UK  .n  the  development  of 
two  particular  semi-automatic  tools,  MALPAS  (MAl.vern 
Erogram  Analysis  Suite),  and  SPADE  (Southampton 
Erogram  Analysis  and  Qevelopment  Environment).  Both 
tools  automate  the  process  of  static  code  analysis,  which 
previously  had  only  been  possible  using  largely  manual 
low-integrity  techniques  such  as  code  reviews, 
walkthroughs,  etc.  The  tools  pUi  the  process  onto  a 
sound  mathematical  basis,  which  lends  itself  to 
automation,  and  therefore  potentially  makes  them  a 
practical  proposition  when  considering  the  development  of 
relatively  large  systems. 

8.2  In  broad  terms,  the  tools  first  carry  out  a  number  of 
standardised  checks  using  computer  analysers  (see  Fig 
8): 

I  Control  Flow  Analysis,  where  the  analyser 
examines  the  program  structure  to  identify  all  possible 
starts  and  ends,  unreachable  code,  black  holes,  and  the 
location  of  entry  and  exit  points  of  loops 

II  Data  Use  Analysis,  where  the  analyser  checks  that 
all  inputs  and  outputs  of  the  program  are  identified,  and 
that  the  data  is  used  correctly  e.g  data  is  not  read  before 
It  IS  written,  or  is  not  written  more  than  once  before  it  is 
read 

III  Information  Flow  Analysis,  where  the  inputs  on 
which  each  output  depends  are  identified 

IV.  Semantic  Analysis,  where  the  relationship  between 
inputs  and  outputs  is  determined  This  is  a  very  powerful 
part  of  the  process,  and  allows  the  program  to  be 
compared  directly  with  its  specification.  This  can  be 
further  aided  by  the  use  of  a  Compliance  Analyser,  which 
aliows  this  process  to  be  carried  out  automatically 

3  3  The  principal  benefit  of  the  tools  is  the  assistance  in 
the  initial  design  of  software.  At  this  stage,  the  tools  can 
be  used  to  provide  an  immediate  check  on  how  the 
software  meets  the  requirements,  helping  to  reduce  the 
number  of  errors  carried  forward, 

9  DOCUMENTATION 

9  1  Adequate  and  timely  documentation  is  vital  to  the 
development  orgonisation,  as  weh  as  to  the  certifying  and 
accepting  agencies.  Of  critical  importance  is  early 
discussion  and  agreement  of  precisely  what 
documenkation  the  customer  and  his  agencies  require  of 
the  contractor.  Not  only  is  a  record  needed  of  the 
deliverable  design,  but  often  a  full  record  of  how  that 
design  was  arrived  at. 

9.2  The  criticality  of  the  documentation  produced 
recording  the  development  process  and  the  design  of  the 
software  as  it  progresses  through  this  is  clear:  No  amount 
of  testing  ot  the  final  system  will  give  anything  like 
assuiance  that  the  complex  software  program  in  any 
practical  avionic  system  of  today  or  the  future  is  100% 
fault  free,  that  it  fully  meets  the  requirements  of  the 
specification,  and  only  those  requirements.  Therefore,  we 
must  depend  to  a  large  extant  upon  the  software  having 
been  ’designed-right’  to  meet  the  specification  in  the  first 
place. 

9  3  A  basic  requirement  is  ‘herefore  that  designers  must 
take  a  disciplined  approach  to  the  development  of  the 
system.  From  requirements  definition,  through  design, 
code  and  Integration,  to  final  testing,  there  must  be  a 
properly  structurod  and  recorded  process  of 
documentation  and  review  (s,.o  Fig  9). 
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9.4  This  IS  a  common  requirement  in  both  civil  and  military 
avionic  applications,  and  is  particularly  critical  for  avionic 
systems  having  flight  safety  ii, .plications  It  should  be 
noted  that  there  is  considerable  common  ground  between 
the  documentation  requirements  of  the  principal  military 
standard  DOD-STD-2167A  and  the  civil  document  RTCA 
(Radio  Technical  Commission  for  Aeronautics)/DO-178A 
'Software  Considerations  in  Airborne  Systems  and 
Equipment  Cedification'^  There  is  also  a  continuing  need 
for  refinement  of  these  requirements,  in  line  with  the 
advancement  of  technology. 

10  SYSTEM  SAFETY  IMPLICATIONS 

10  1  The  increasing  complexity  of  software  based  avionic 
systems  brings  with  it  a  concurrent  increase  in  the  amount 
o'  software  that  has  a  direct  bearing  upon  the  integrity  of 
the  aircraft.  It  is  extremely  difficult  to  prove  that  the 
software  for  practical  systems  is  100%  correct,  and  the 
problems  that  result  are  becoming  increasingly 
significant  Techniques  that  ensure  that  software  is 
correct  to  the  limits  of  the  'State  of  the  Art'  need  to  go 
hand-in-hand  with  adequate  protection  at  system  level 
from  the  effects  of  any  remaining  bugs  in  the  software 

10.2  The  design  aim  must  always  be  the  ultimate 
certification  of  the  system.  Target  integrities  for  sub¬ 
system  components  depend  upon  a  number  of  factors,  of 
principal  importance  being  the  overall  required  integrity  of 
the  aircraft  as  a  complete  system.  It  is  essential  that  the 
software  contribution  to  system  integrity  is  quantified  as 
far  as  possible  from  the  earliest  stages  of  a  development 
project  (principally  by  a  process  of  hazard  analysis);  this 
IS  in  order  that  an  assessrient  can  be  made  as  to  whether 
or  not  the  design  will  be  \  lable,  and  so  that  levels  of 
verification  and  validation  can  be  determined  prior  to  the 
proces  i  of  software  design 

10.3  In  ihe  UK,  the  potential  problems  have  been 
recognised  for  many  years  We  have  for  some  time  been 
successfully  applying  the  requirements  of  the  civil 
aviation  document  RTCA/DO-170Ato  military  avionic 
software  having  flight  safety  implications.  This  document 
IS  currently  being  revised  by  RTCA,  reflecting  the 
considerable  advance  in  technology  that  has  occurred 
since  it  was  published  in  1985 

10.4  The  requirements  o<  RTCA/DO-178A  have  been 
called  up  in  slightly  modified  form  in  a  UK  Interim  Defence 
Standard  no-31  'The  Development  of  Safety  Critical 
Software  for  Airborne  Systems''®,  published  in  1987 
However,  the  range  and  complexity  of  functions  controlled 
by  embedded  computer  systems  in  aircraft  is  expanding 
rapidly,  providing  ever  more  numerous  and  more  subtle 
opportunities  for  errors  in  so'tware  design  These 
problems  are  not  solely  confined  to  aircraft  systems;  it 
has  been  determined  in  the  UK  that  the  current  approach 
to  the  development  of  such  systems,  which  is  based  upon 
system  testing  and  oversight  of  the  design  process  will,  in 
the  long-term,  become  cumbersome  and  inefficient  for  the 
assurance  of  safety 

10.5  This  realisation  has  led  to  the  recent  publication  of 
two  Tri-Service  Interim  Defence  Standards  that  will  have 
major  impiicaiions  on  me  way  mat  future  systems  are 
designed  and  built.  Int  Del  Stan  00-55  The  Procurement 
of  Safety  Critical  Software  in  Defence  Equipment'", 
together  with  an  associated  Int  Def  Stan  00-56  'Hazard 
Analysis  and  Safety  Classification  of  the  Computer  and 
Programmable  Electronic  System  Elements  of  Defence 
Equipment''^  introduce  a  number  of  new  requirements,  the 
most  impiortant  of  which  are  briefly  listed  below; 


i.  All  systems  (from  the  highest  level  down  to  the  lowest 
sub-system)  to  be  thoroughly  analysed  for  the  existence 
of  safety  critical  hazards,  from  the  outset  of  the  project 
lifecycle 

II  Safely  Planning  as  a  distinct  activity  to  be  carried  out 
from  the  earliest  stages  of  a  project 

Ml.  Formal  Mathematical  Methods  to  be  applied 
throughout  the  software  requirements  definition  and 
design  process 

IV.  Defensive  programming  techniques  to  be  applied 

V  The  application  of  automated  static  code  analysis 

vi.  The  formalisation  ol  responsibilities  in  the  project 
organisations  (Procurement  Project  Manager,  Design 
Authority,  etc),  together  with  a  requirement  for  formally 
independent  groups  to  carry  out  verification  of  the 
software,  and  assessment  ot  the  work  of  the  Design 
Authority 

VII.  A  comprehensive  documentation  programme,  not 
only  recording  the  design  and  its  development  process, 
but  also  how  safety  aspiects  had  been  analysed  and 
controlled 

11.  SUPPORTABILITY,  AND  THE  ROLE  OF 
SUPPORTABILITY  ANALYSIS 

11.1  Life  Cycle  Costs  (i  e  the  overall  cost  of  ownership) 
are  an  increasingly  important  design  driver  in  the 
development  of  military  avionic  systems,  in-service 
support  costs  form  a  major  (perhaps  the  major) 
component  of  this,  and  therefore  refinement  and  even 
optimisation  of  the  design  to  minimise  these  is  an 
important  consideration.  Logistics  Support  Analysis  has 
been  available  for  soma  time  (e  g  MIL-STD-1388-1 A 
'Military  Standard  -  Logistic  Support  Analysis’’®),  as  a 
system-wide  technique,  with  the  aim  of  optimising  the 
design  to  meet  the  needs  of  in-service  support,  and 
identifying  the  most  cost-efficient  supjxirt  option  for  each 
component  of  the  system  (in  terms  of  who  should  be 
carrying  out  the  work,  facilities,  manpower,  etc).  The 
increasing  software  component  in  systems  means  that 
particular  attention  is  needed  to  this  component  area, 
right  through  from  concepts  to  detail  design,  due  to  the 
great  effect  upon  supportability  that  software  features 
can  have  New  standards  are  likely  to  emerge  for  the 
prediction  of  the  support  requirements,  focussing  on  the 
need  for  rational,  structured  examination  of  the  software 
requirements 

1 1  2  The  in-service  software  maintenance  task  consists 
of  several  components 

I.  Correcting  design  faults.  These  include  both  faults  in 
the  software  compared  to  its  specification,  as  well  as 
errors  in  the  original  specification  itself  Many  faults  in 
software  cased  systems  can  be  traced  back  to  aii 
incomplete,  impreciso,  or  incorrect  description  of 
requirements.  Correcting  faults  ones  a  system  has  gone 
■nto  service  is  the  hardest  and  mos*  expensive  option, 
ana  every  ettort  should  be  made  to  minimise  these 

II.  Incorjaorating  minor  modifications,  to  meet  new 
operational  requirements,  or  existing  requirements  that 
were  not  fully  undo-'Stood  when  the  original  specific  jtion 
was  produced 

1 1.3  The  Supportability  Analysis  for  Software  (SAS) 
process  should  be  continuous,  and  should  run  in  parallel 
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With  and  throughout  the  life  cycle  of  the  subject  system 
Ideally,  it  should  commence  prior  to  the  point  in  time  where 
the  need  for  software  has  been  identified  and  software 
requirements  analysis  is  about  to  start  -  much  of  the  data 
needed  to  start  the  analysis  is  available  before  this, 
perhaps  even  as  eariy  as  during  initial  feasibility  studies. 
The  process  cc.n  be  broken  down  into  four  phases  (see  Fig 
10). 

I  Initial 

II  Preliminary 
III.  Detailed 

IV  Update/Tracking 

1 1  4  At  each  phase,  analyses  may  be  carried  out  that  can 
be  grouped  under  the  following  headings. 

I  Software  Identification  and  Categorisation 

II  Software  Support  .Anr'ysis 

III  Software  Supportability 

IV  Software  Support  Concept  Analysis 

1 1 .5  Outputs  from  these  analyses  should  take  the  form  of 
a  number  of  standard  format  reports,  which  can  then  be 
used  as  a  basis  for  design  refinr  ,nent,  as  well  as  to  plan 
for  the  in-service  support  phase 

1 1  6  Ore  of  the  important  factors  in  considering 
supportability  needs  is  the  rate  of  change  traffic  that  is 
likely,  either  to  correct  faults  or  to  meet  new  or  unforseen 
requirements  Unfortunately,  it  is  most  difficult  to  predict 
this  during  the  early  stages  of  design,  and  there  are 
currently  no  known  validated  models  that  provide 
prediction  of  this.  Further  developments  here  are  likely  to 
be  of  importance 

1 1  7  The  SAS  process  undoubtedly  involves  up-stream 
expenditure  in  order  to  generate  down-stream  benefits 
and  cost  savings.  Looking  at  current  and  past 
programmes  over  a  broad  range  of  applications,  between 
50%  and  70%  of  the  overall  cost  of  the  software  life-cycle 
has  been  consumed  by  the  maintenance  phase,  when 
considering  a  10-year  service  life.  Given  the  likely 
service  life  of  many  military  avionic  systems  (perhaps  20 
years  or  more),  the  likely  benefits  for  optimisation  of  the 
design  and  fonward  planning  of  support  requirements  are 
not  to  be  ignored 

12  THE  EVOLUTION  OF  STANDARDS 

1 2  1  The  rapidly  evolving  technology  in  the  f'eld  of 
software  engineering  brings  with  it  a  parallel  need  for 
evolution  of  the  Standards  that  prescribe  design  and 
development  requirements  Important  new  techniques 
such  as  automated  verification  and  validation  tools, 
formal  mathematical  methods,  etc  must  be  taken  account 
of,  following  adequate  research  and  demonstration, 

12  2  However,  care  is  needed  in  the  Standards 
generation  process  not  to  be  over-prescriptive  in  how  a 
doliverabie  product  is  achieved  There  should  rather  be 
concentration  on  the  essential  qualities  of  the  product, 
and  avoidance  of  the  specification  or  discouragement  of 
the  use  of  particular  software  development  tools, 
methods,  techniques,  etc  An  important  component  is  the 
specification  of  the  vital  qualities  required  in  whatever 
processes  are  selected  by  a  development  organisation. 


and  what  information  is  required  to  support  acc 
a  system  as  suitabie  for  its  intended  purpose  As  much 
scope  as  possible  should  be  left  to  the  development 
organisation  to  seiect  the  methods,  techniques,  toois,  etc 
that  best  suit  its  particuiar  needs. 

13.  MODULAR  AVIONICS 

13 1  Present-Day  Federated  Architectures 

13  1  1  Current  LRU  (Line  Replaceable  Unit)  based 
■federated'  avionic  architectures  (see  Fig  11)  consist  of  a 
number  of  separate  subsystems  Each  subsystem 
performs  a  defined  set  of  processing  functions,  as  and 
when  required,  and  does  not  have  the  capability  to  carry 
out  new  functions  as  a  result  of  changing  circumstances 
e  g  damage  to  a  subsystem  requiring  some  or  ali  of  its 
processing  functions  to  b  transferred  to  some  other 
subsystem. 

13.1.2  Subsystems  are  connected  together,  either  by 
hardwire  connections,  or  by  one  or  more  standard 
databuses.  The  number  of  physicai  interfaces  of  any  one 
subsystem  with  other  subsystams  is  kept  to  a  minimum, 
for  a  variety  or  reasons,  including  reliability  of  connectors, 
physical  space  and  weight,  etc. 

13.1.3  Each  subsystem  may  have  great  internal 
complexity  within  its  LRUs,  containing  a  number  of 
processors,  sensor  interfaces,  power  supplies  and  so  on 
However,  these  structures  are  invisible  to  the  other 
subsystems  with  which  it  operates.  Its  operation  within 
the  avionic  system  is  determined  by  the  characteristics  of 
the  messages  it  can  send  or  receive  via  its  interfaces 

1314  The  architectural  design  of  this  system  is 
functional  based.  Individual  physical  components  with 
defined  functions,  operating  together  but  in  a  'loose- 
coupled'  way,  provide  the  total  functionality  required 
There  is  generally  great  diversity  in  the  range  of 
component  enclosures  within  one  aircrafts'  avionic 
systems,  and  between  different  aircraft  types 

13  2  The  Modular  Solution 

13.2.1  The  core  concept  (see  Fig  12)  is  that  a  processing 
system  built  from  a  range  of  standardised  modular 
components,  or  LRMs  (Line  Replaceable  Modules),  would 
fornr  the  core  avionic  architecture,  in  which  many  of  the 
processing  functions  e.g  navigation,  communications, 
weapons  control,  displays,  etc  would  reside  These 
processing  functions  in  the  present-day  federated 
architectures  wouid  have  resided  in  the  discrete  LRU 
enclosures  peculiar  to  the  particular  *unction. 

13  2  2  Fundamental  features  of  the  core  architecture  are 
that  It  IS  built  from  a  limited  range  of  standardised  LRMs 
providing  processor,  memory,  data  bus,  etc  functions,  the 
system  may  be  expanded,  reduced  or  reconfigured  to 
meet  a  number  of  mission  requirements  in  different  aircraft 
types;  reconfiguration  may  indeed  be  an  active  feature  of 
the  system,  to  protect  against  component  failures  and 
battle  damage,  greatly  increasing  the  availability  of  the 
systern  The  system  will  be  cophgured  by  software  into  a 
functioning  entity,  and  the  useful  functions  o!  the  system 
I  e  the  operations  on  inputs  to  produce  required  outputs 
will  be  software  driven. 

13.2 The  soff.vare  problem  that  this  presents  poses  a 
major  step  forward  in  terms  of  complexity  for  avionics,  and 
will  require  the  development  of  a  highly  capable  Real-Time 
Operating  System  to  handle  the  configuration  of  the 
hardware  components,  to  provide  the  distribution  of  tasks 
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around  the  network,  and  to  provide  the 
reconfiguration/fault  tolerance  features  needed.  Existing, 
commercial  systems  may  offer  some  scope  to  act  as  a 
starting  point  for  the  development  of  such  a  system 
(although  this  seems  unlikely).  A  considerable  amount  of 
effort  and  expenditure  will  be  needed  to  make  the 
Operating  System  a  working  reality  in  the  avionic 
environment 

13  3  Principal  Impacts  of  Modular  Avionics  on 
Software  Design 

13  3  1  The  definition  of  an  optimised  modular  avionic 
architecture  and  its  associated  software  component  is  a 
major  task,  currently  the  subject  of  a  number  of  national 
and  international  init'atives.  It  would  be  inappropriate 
therefore  at  this  present  time  to  speculate  in  great  detail 
about  the  final  form  of  such  a  system  It  is  also  beyond 
the  scope  of  this  paper  to  discuss  hie  system  engineering 
and  hardware  related  considerations,  such  as  the 
optimum  range  and  capabilities  for  the  LRM  types;  ways  of 
connecting  LRMs  together,  the  overall  architectural 
concepts  for  the  assembly  of  the  variety  of  LRMs  together 
to  build  a  practical  system;  and  so  on.  There  are  however 
a  number  of  general  considerations  relating  to  the 
software  component,  that  may  be  usefully  highlighted; 

I  With  federated  LRU-based  systems,  the  wide  range  of 
processors  and  software  programming  methods  available 
leads  to  a  strong  tendency  for  components  that  are 
considered  optimum  for  particular  applications  to  be  used 
The  result  is  a  number  of  different  processors  and 
programming  methods  are  used  in  the  subsystems  that 
make  up  the  complete  avionics  suite  This  plurality  leads 
to  high  costs  of  system  maintenance  when  the  system  is 
in  service,  because  of  the  wide  range  of  hardware  and 
software  support,  spare  parts  and  maintenance  personnel 
needed  Modular  LRM-based  architectures  offer  the 
potential  to  minimise  this  component  of  Life  Cycle  Costs, 
because  of  the  ability  to  standardise  on  many  if  not  all  of 
the  software  components,  as  well  as  the  development  and 
support  environments  (facilities,  software  tools, 
personnel,  etc). 

II.  Functions  may  not  need  to  be  uniquely  assigned  to 
particular  processors  or  groups  of  processors,  making 
redundant  the  concept  of  subsystems  each  with  a  defined 
set  of  functions.  The  mooular  architecture  couk),  in 
effect,  form  a  single  computing  system  built  from  a 
number  of  identifiable  module  components.  All  the 
processing  functions  would  reside  within  this  system,  and 
the  processing  would  be  a  function  of  the  whole  system 
rather  than  of  particular  modules. 

Ill  Existing  federated  LRU-based  systems  can  suffer  from 
restricted  availability  The  reliability  of  individual  LRUs 
within  the  system  may  be  very  high  in  terms  of  failures  per 
flying  hour,  but  the  overall  probability  for  the  aircraft 
system  of  loss  of  one  or  more  functions  may  be 
unacceptably  high  when  taking  the  overall  system 
complexity  into  account.  This  situation  may  be  improved 
to  some  extent  by  incorporating  redundant  processing 
into  individual  subsystems,  but  this  carries  significant 
vreight  volume,  and  cost  jjenalties  which  .may  bo  as 
unacceptable  as  the  problem  they  are  trying  to  solve 

The  modular  LRM-based  architecture  offers  the  potential 
ability  to  provide  fault  tolerance  efficiently  The 
architecture  would  be  able  to  continue  operation  even  ;f 
one  or  several  of  the  modular  components  had  failed.  If 
sufficient  spare  capacity  has  beer,  built  into  the  system, 
and  there  is  the  facility  to  configure  the  functions  into  the 
reduced  system  available,  full  system  functionality  can  be 


maintained.  The  impact  on  the  software  design  would  be 
that  very  capable  Built  In  Test  (BIT)  functions  would  be 
needed  to  detect  that  components  of  the  system  had 
failed,  and  to  diagnose  them  correctly;  reconfiguration 
software  would  be  needed  to  allcw  processing  to  continue 
to  meet  the  full  system  requirements  with  the  reduced 
hardware  than  available.  This  reconfiguration  must  be 
carried  out  dynamically,  during  a  mission,  with  minimal 
elect  upon  the  other  functions  handled  by  the  system 
Note  that  this  fault  tolerance  is  in  fact  a  function  of  the 
system  design  (although  implemented  in  the  software) 
rather  than  due  to  inherent  fault  tolerance  in  the  software. 

It  seems  unlikely  in  the  foreseeable  future  that  inherently 
fault-tolerant  software  will  have  any  practical  impact  upon 
the  design  of  such  systems 

13.4  Software  Philosophy  for  the  Modular 
System 

t3,4.l  There  is  a  range  of  top-level  concepts  that  could 
be  applied,  including: 

I.  A  single  program  for  the  entire  system.  All  the  system 
functions  would  then  be  designed  in  without  reg.'.rd  for  the 
way  in  which  functions  would  be  distributed  around  the 
system.  This  step  would  be  accomplished  automatically, 
perhaps  as  a  function  ol  the  development  system,  or 
perhaps  as  a  capability  of  the  Real-Time  Operating 
System. 

II  One  program  per  node.  Functions  are  distributed  during 
development  to  processing  nodes  within  the  architecture, 
perhaps  consisting  of  a  number  of  closely  coupled 
processors  This  greatly  simplifies  the  problem  of  the 
software  needed  to  distribute  functions  around  the 
system,  but  may  seriously  reduce  the  ability  to 
reconfigure  the  system  whilst  in  operation 

III  One  program  per  processor.  A  sim,  ler  solution  again; 
existing  programming  languages  such  as  Ada  may  be 
used  to  develop  the  programs  for  each  particular 
processor,  which  are  compiled,  linked,  and  loaded 
conventionally,  to  provide  a  defined  set  of  functions 
However,  this  solution  restricts  the  ability  to  reconfigure 
the  system  to  meet  new  situations  such  as  the  loss  of 
certain  modules.  Any  reconfiguration  options  would  have 
to  be  programmed  into  the  system  along  with  the 
functional  software. 

The  higher  the  level  of  the  task  distribution  process,  the 
more  complex  becomes  the  development  system  and  the 
resident  Operating  System,  and  hence  the  cost  of  those 
features  increased  automation  of  the  software 
generation  process  may  lead  to  reduced  direct  costs  for 
the  developm,9nt  of  the  target  software,  but  again 
increased  cost  of  the  software  development  system.  The 
lower  the  level  ol  distribution,  the  more  restricted 
becomes  the  possible  scope  of  reconfiguration  software 
Clearly,  a  trade-ofi  between  a  number  of  such  factors  is 
required  in  order  to  determine  the  optimum  solution  in 
terms  of  overall  Life-Cycle  Costs. 

13.4  2  Ttie  primary  objective  of  the  modular  solution  is  to 
reduce  Life  Cycle  Costs,  compared  to  those  associated 
with  federated  LRU-bas^  systems.  A  major  comjxrnent 
cf  these  costs  is  in  software  maintenance,  A  key  factor  in 
the  cost-saving  strategy  is  therefore  likely  to  be  a  rigid, 
modular,  and  multilayer  software  architecture;  this  is  in 
order  that  modifications  and  updates  can  be  undertaken 
on  parts  of  the  system,  without  the  need  for  extensive 
redesign  of  other  parts  (see  Fig  13). 
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13.4  3  In  broad  terms,  there  are  likely  to  be  two  principal 
'layers'  of  software  in  the  system: 

I  Real-Time  Operating  System  Software  -  all 
software  within  the  system  that  is  independant  of  the 
particular  application.  The  Operating  System  in  effect 
configures  the  hardware  into  a  functioning  processing 
system,  and  supports  the  operation  of  the  application- 
specific  software.  Sub-levels  of  the  Operating  System 
may  include: 

Board  Specific  Software,  the  lowest  level,  specific  to  the 
particular  processing  boards  used  in  the  system, 
interfacing  between  the  bare  hardware  and  the  Kernel 

Kernel:  components  of  the  Operating  System  that  reside 
on  every  processing  node  in  the  architecture 

Operating  System  Support;  components  of  the  Operating 
System  that  reside  on  only  certain  processing  elements 

II  Application  Software  -  Software  specific  to  the 
particular  mission  functions  that  the  avionic  system  is 
required  to  provide  to  the  aircraft  Sub-levels  of  the 
Application  Software  may  include' 

Application  Software  Support;  software  that  supports 
operation  of  the  applications,  but  which  does  not  relate 
directly  to  specific  mission  functions 

Applications,  software  that  performs  the  specific  mission 
functions  i  e  that  provides  the  mission  algorithms 

13  4.4  The  Real-Time  Operating  System  will  need  to 
provide  effective  partitioning  of  software  of  d,f<erent 
safety  crilicalities  This  may  only  be  practically 
achievable  by  isolating  flight  critical  functions  to  a 
particular  area  of  the  architecture,  with  high  integrity 
control  of  data  entering  or  leaving  that  area.  A  related 
problem  is  the  control  of  secure  (i  e  classified)  data. 

13  4  5  The  Real-Time  Operating  System  should  provide 
the  capability  for  additional  or  updated  Application 
Soft  (are  components  to  be  idded  to  an  existing  system, 
wi'hout  the  need  for  large  parts  or  even  the  entire  system 
to  be  rebuilt 

13.4.6  Highly  capable  BIT  (Built  In  Test)  functions  will  be 
an  important  component  of  the  Real-Time  Operating 
System  This  will  need  to  provide  diagnosis  down  to  at 
least  LRM  level,  and  probably  to  functional  elements  of  an 
LRM  where  appropriate  Full  logging  of  fault  events  will 
also  be  required  to  assist  in  future  maintenance  Principal 
areas  for  BIT  include 

Data  validation 
Hardware 
Software 
Communications 

The  software  will  need  to  adapt  the  system  configuration 
in  the  event  of  events  such  as  LRM  failure  or  battle 

I,  wiow  ■lUVMor  tw  pivtiw  Cvi iti viteu 

in  situations  where  insufficient  processing  resources  are 
available  to  support  the  entire  application  functions 
demanded. 

13  4.7  The  Real-Time  Operating  System  will  need  to 
provide  adequate  safeguards  to  prevent  events  such  as 
illegal  accessing  or  modification  of  data  in  memory  by 
faulty  software  modules  The  integrity  and  reliability  of  the 
system  will  be  particularly  dependant  upon  the  software 
that  controls  reconfiguration  and  fault-tolerance 


13.4.8  As  far  as  possible,  the  Application  Software 
should  be  independant  of  the  particular  architectures 
defined  for  individual  aircraft  types  and/or  applications 
This  IS  to  promote  the  reusability  of  these  so'tware 
components  across  a  range  of  aircraft  types,  and  should 
be  achievable  by  effective  layering  of  the  software 
system.  Application  Software  being  isolated  from  the 
Real-Time  Operating  System  by  some  sort  of  abstract 
interface. 

13.5  Risks 

The  success  of  the  modular  system  will  be  heavily 
dependant  upon  the  practical  realisation  of  a  very 
complex,  distributed  Real-Time  Operating  System,  and 
this  must  be  considered  the  principal  risk  area  In  terms 
of  magnitude  of  code  the  Operating  System  will  be 
equivalent  to  several  million  lines  of  source  cods,  and  the 
development  cost  will  form  a  considerable  proportion  of 
the  total  integrated  system  development  cost. 
Summarising,  the  leading  functions  of  the  Real-Time 
Operating  System  will  probably  include  exercise  of  overall 
system  control  in  this  highly  distributed  processing 
environment,  allocation  of  processing  resources  to  the 
Applications  Software,  and  control  of  the  reconfiguration 
of  the  system  as  made  necessary  by  failure  of  component 
modules  whilst  in  use. 

14  REUSABILITY 

14.1  The  move  towards  modular  architectures  will  g.'eally 
increase  the  scope  lor  reusability  of  software 
components.  The  use  of  common  hardware  modules 
across  a  range  of  aircraft  types  has  largely  been  the 
focus  of  attention  in  the  activities  investigating  modular 
avionics  thus  far,  but  it  is  perhaps  in  the  software  that  the 
greatest  scope  exists  for  the  reduction  in  Life  Cycle  Costs 
demanded 

14.2  The  major  source  of  commonality  is  likely  to  be  the 
Real-Time  Operating  System  At  the  highest  level  of 
abstraction,  this  has  the  function  of  configuring  the  set  of 
hardware  modules  into  an  integrated  system,  and  of 
providing  support  for  the  Applicat'ons  Software  that 
implements  the  required  system  functionality.  It  is 
therefore  likely  to  be  applicable  to  all  systems  making  use 
of  the  common  modules,  and  may  be  considered  as  a 
reuseable  component  in  itself 

14  3  At  lower  levels,  there  is  also  scope  for  reuse  of 
components  of  Applications  Software  from  one  system  to 
another. 

14.4  A  potential  difficulty  however  is  in  the  design  liability 
for  defective  operation.  Cost  savings  in  the  reuse  of 
software  components  across  a  number  of  manufacturers 
for  different  applications  are  dependant  to  some  extent 
upon  the  ability  to  rely  upon  verification  and  validation 
work  already  carried  out  by  the  original  design  company. 
However,  it  would  appear  that  even  if  a  complete  rerun  of 
the  V  &  V  activities  is  considered  necessary  for  each  new 
application,  there  would  still  be  worthwhile  cost-savings, 
Thts  is  as  a  result  of  the  lack  of  a  need  to  rerun  the  design 
process  from  scratch 

14  5  Increasingly,  commercial  software  systems  are 
incorporating  features  which  are  common  to  the  needs  of 
avionic  systems,  at  the  system  engineering  level. 
Operating  systems  for  distributed  processing 
architectures  are  already  in  use  for  specialist  commercial 
computing  applications,  and  the  adoption  of  Ada  for  the 
design  of  commercial  systems  is  likely  to  further  enhance 
the  potential  for  commonality. 
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15  KEY  SOFTWARE  TECHNOLOGY  ASPECTS 
FOR  THE  FUTURE 

15  1  In  condijsion,  the  key  technology  aspects  for  the 
future  ot  avionic  software  engineering  may  be  summarised 
as. 

I  A  need  to  refine  continuously  life-cycle  models  for  the 
development  process,  in  line  with  advancing  technology. 
Models  to  be  backed  up  by  the  necessary  procedures, 
documentation  programmes  etc 


III.  An  increasing  use  of  formal  mathematical  methods, 
from  the  earliest  stages  of  soocification,  through  design, 
to  verification 

IV.  A  progressive  increase  in  productivity  of  executable 
code,  probably  brought  about  by  the  increasing 
automation  of  each  process  in  the  lifecycle 

V  The  development  of  reusable  software  components, 
principally  in  the  area  of  the  Real-Time  Operating  System 
for  the  new  modular  architectures  now  appearing 


II  A  need  for  more  capable  requirements  definition 
techniques,  capable  of  handling  the  very  great  complexity 
likely  in  the  next  generation  of  aircraft  systems 


VI  A  growth  in  the  application  of  in-service  supportability 
analysis,  from  the  earliest  stages  of  development.  This 
needs  to  be  implemented  by  a  formalised,  automated 
process  as  far  as  possible 
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INTRODUCIION 

Because  of  the  rising  costs  associated  with  the 
development  and  production  of  aviation  electronics  (avionics) 
there  is  increasing  interest  in  opponunities  to  more  effecttvely 
use  the  United  States  defense  dollars  spent  on  the  development 
and  procurement  of  avionics.  Over  the  last  several  years, 
efforts  to  control  the  proliferation  of  avicnics  have  yielded 
some  promising  results  by  simply  expanding  the  application  of 
avionics  equipment  to  more  than  one  airaaft.  It  is  widely 
postulated  that  a  key  to  conserving  defense  dollars  may  be 
through  broader  avionics  commonality  applications.  More 
recently,  evolution  of  integrated  architecture  along  with 
significant  advances  in  technology  in  processing  and  storage 
capacity  have  resulted  in  a  clear  opportunity  to  develop  an 
avionics  architecture  and  a  series  of  avionics  building  blocks 
(common  standard  modules)  that  may  be  used  in  a  wide  variety 
of  applications,  both  within  a  weapon  system  and  between 
weapons  systems.  With  careful  attention  to  designs  which 
permit  growth  and  technology  insertion,  this  concept  could 
support  weapons  systems  now  and  for  many  years  into  the 
future.  This  is  the  challenge  the  United  States  Congress  gave 
to  the  U  S.  Army,  Air  Force  and  Navy  over  four  years  ago  and 
has  been  the  objective  of  the  Joint  Integrated  Avionics 
Working  Group  (JIAWG)  since  its  inception.  This  paper  will 
present  the  efforts  of  the  three  services  to  develop  a  Common 
Avionics  Baseline  (CAB),  the  primary  product  of  the  JIAWG. 

Today  the  Common  Avionics  Baseline  is  a  preliminary 
set  of  functional  performance  specifications  for  development 
tools,  draft  architectures,  multiplex  busses,  common  modules 
and  support  requirements.  These  specifications  form  the  basis 
for  a  dramatic  step  toward  offering  the  United  States 
Department  of  Defense  an  avionics  capability  which,  with 
some  application  specific  adjustments,  could  serve  the  needs  of 
a  wide  vanety  of  users  well  into  the  future.  At  this  writing,  the 
Common  Avionics  Baseline  is  evolving  and  maturing.  As  will 
be  discussed,  we  have  actually  built  prototypes  of  various 
hardware  and  software  pieces  that  will  eventually  become  the 
validated  Common  Avionics  Baseline.  However,  due  to  the 
complexities  of  competitive  procurement,  the  wide  ranging 
application  dependent  performance  requirements  imposed  on 
these  products,  and  the  lengthy  process  available  to  produce 
hardware  and  software,  considerable  effort  remains  before 
success  will  be  declared.  The  path  to  a  preliminary  CAB  has 
been  paved  with  obstacles  ranging  from  the  complexities  of 
completing  input/output  definitions  for  a  common  data 
processor  and  the  impacts  of  nuclear  Transient  Radiation 
Effects  on  Electronics  (TREE)  hardening  of  the  entire 
Common  Avionics  Baseline  suite,  to  dealing  the  proprietary 
rights  of  the  design  of  several  critical  potential  comnxin 
standard  processing  modules.  As  will  be  described,  we  are 
presented  with  an  opportunity  to  eventually  realize  success  in 
the  form  of  a  proven  implementation  of  a  Common  Avionics 
Baseline  Figure  1  is  a  generic  representation  of  one  possible 
implementation  of  the  CAB  to  produce  an  integrated  avionics 
capability.  The  opportunity  to  create  this  capability  is  the 
direct  result  of  the  efforts  of  the  JIAWG. 


WHY  BUILD  A  CAB 

As  mentioned  earlier,  the  motivation  behind  this  effon 
was  a  recognized  need  to  manage  the  Defense  Budget,  in  this 
case  by  controlling  the  proliferation  of  avmnics,  as  rightfully 
perceived  by  the  United  States  Congress.  As  can  be  seen  in 
Figure  2,  the  cost  of  avionics  for  our  newer  aircraft  has  become 
an  increasingly  larger  part  of  the  procurement  and  fly-away 
cost  of  new  weapon  systems.  The  commonly  held  view  is  that 
there  are  economic  advar.”>ges  in  the  improved  reliability, 
supportability  and  interoperability  inherent  in  the  new 
technology  available  for  common  avionics,  which  if  achieved 
can  attain  the  required  perfomiance  capabilities  needed  by  the 
implementing  weapon  systems  while  offering  the  potential  for 
substantially  reduced  avionics  cost. 

Several  years  ago,  the  results  of  a  wide  variety  of 
technology  based  programs  targeted  to  support  the  next 
generation  of  avionics  were  beginning  to  demonstrate 
remarkable  advances  in  processing  capabilities  using 
architectural  structures  compatible  with  fault  tolerant, 
reconfigurable,  multi-application  features.  Programs  such  as 
PAVE  PILLAR  (focused  on  advanced  architectural  concepts). 
Integrated  Communication  Navigation  Identification  Avionics 
(ICNIA  -  directed  at  integration  of  communication,  radio 
navigauon,  identification.  Joint  Tactical  Information 
Distribution  System  (JTTDS),  Global  Positioning  System 
(GPS),  Instrument  Landing  System  (ILS),  Miaowave  Lanilmg 
System  (MI.S),  etc.,  in  a  common  architecture).  Integrated 
Electronic  Warfare  System  (INEWS  -  integrating  electronic 
combat  functions  in  a  common  architecture)  and  DOD  VHSIC 
insemon,  all  Air  Force  technology  base  efforts,  were 
established  to  individually  address  growth  and  enhancement  to 
mote  reliable  specific  avionics  functions.  As  word  of 
successes  in  advancing  the  avionics  state-of-the-art  spread,  an 
exaggerated  view  of  the  maturity  of  these  discrete  technologies 
emerged.  In  this  case,  the  exaggeration  was  good  fortune 
because  it  added  significantly  to  the  empetise  to  consider  tlie 
application  of  an  aggressive  integrated  avionics  capability  on 
the  next  aircraft  to  be  built  by  one  of  the  services. 

Although  no  demonstration  of  a  full,  integrated 
avionics  suite  embodying  the  capabilities  of  the  evolving 
technology  base  has  been  accomplished,  a  series  of  windows  of 
opportunity  are  available  in  the  form  of  the  concurrent 
developments  of  the  Army  Light  Helicopter  (LH),  the  Air 
Force  Advanced  Tactical  Fighter  (ATF),  and  the  Navy  A-12 
(the  A-6  replacement),  see  Figure  3.  (At  the  time  this  paper 
was  written,  the  future  of  the  A-12  program  and  the  Navy's 
specific  role  in  JIAWG  and  the  CAB  was  uncertain.  For  that 
reason,  the  paper  addresses  the  planned  efforts  as  they  exist 
unadjusted  by  evolving  events  affecting  the  A-12  program). 
Each  of  these  aircraft  were  considered  prime  targets  for  the 
application  of  an  integrated  avionics  capability.  Clearly  the 
development  of  threu  separate  avionics  suites  for  these  three 
weapon  systems  would  continue  the  avionics  proliferation  of 
concern  to  those  who  manage  the  defense  budget.  Based  on 
both  the  technical  and  program  opportunities,  the  decision  to 
pursue  a  common  avionics  capability  applicable  in  the  broadest 
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sense  to  all  three  new  aircraft  was  inevitable.  The  fundamental 
obstacle  was  how  to  merge  the  efforts  of  the  three  services 
with  sufficient  stimulation  to  produce  the  desired  result. 


THE  FORMATION  OF  THE  JIAWG 

As  a  result  of  Office  of  Secretary  of  Defense  (OSD) 
and  Congressional  reaction  to  the  potential  for  avionics  cost 
control  available  from  advances  in  reliability  and 
supportability  directly  available  from  common  integrated 
digital  modular  avionics,  in  October  1986,  the  FY  87  DOD 
Appropnation  Act  Conference  Report  No.  99-1005  was  issued. 
This  report  required  the  U.S.  Army,  Atf  Force  and  Navy  to 
"prepare  a  joint  plan  for  the  inclusion  of  fully  integrate^ 
digital  avionics,  communicadons,  sensors,  embedded 
communications  security,  and  other  electronics  on  all  aircraft 
under  development."  In  response,  the  Assistant  Secretary  of 
Defense  for  ^mmand.  Control,  Communicadon  and 
Intelligence  directed  the  Air  Force  to,  in  coordmadon  with  the 
Army  and  Navy,  propane  a  joint  plan  to  meet  the  intent  of  the 
direction  contained  in  the  Congressional  Appropnadon  Act. 

The  immediate  result  of  this  direction  was  the  trl-service 
formation  of  the  Joint  Integrated  Avionics  Working  Group,  the 
JIAWG. 

Some  of  the  ground  rules  imposed  during  the 
formulation  of  the  JIAWG  were  to  exploit  the  windows  of 
opportunity  created  by  the  coincidentid  dming  of  the  LH,  ATF 
and  A-12  programs;  to  recognize  and  accommodate  the 
compedtive  nature  of  these  three  focus  programs  and  the 
constraints  of  compeddon  on  the  contractors  involved;  to  deal 
with  the  highest  levels  of  classificadon  imposed  by  these  three 
highly  classified  programs;  to  be  prepared  to  work  under  the 
almost  constant  scrudny  of  the  Office  of  the  Secretary  of 
Defense  and  Congress  to  show  steady  progress;  and  to  balance 
the  desire  for  maximum  long  term  savings  from  avionics 
commonality  with  the  reality  of  short  term  cost,  weight,  and 
performance  impacts  to  individual  weapon  systems  which 
might  use  common  avionics. 

Of  these  constraints,  the  most  difficult  was  dealing  with 
compeddve  sensidvity.  It  has  been  essendal  that  the 
contractors  executing  the  weapon  system  programs  be  fully 
involved  in  defining  JIAWG  baseline  requirements.  A 
successful  CAB  definidon  requires  that  muldple  design 
concepts  created  in  a  compeddve  environment  be  minimized  to 
allow  closure  on  a  single  common  requirements  baseline. 
However,  to  preserve  opponunity  of  each  participant  to 
implement  his  preferred  advanced  design,  all  compeddve 
sensitivities  were  scrupulously  honored  when  encountered. 

The  contractors  involved  in  the  JIAWG  have  devoted 
substantial  engineering  effort  to  the  refinement  of  CAB 
requirements  through  analysis  and  debate  among  themselves  of 
the  underlying  technical  issues.  In  order  for  this  process  to 
work,  full  and  open  knowledge  of  the  evolving  CAB  has  been 
the  key.  Any  future  success  of  the  JIAWG  CAB  can  be 
attributed  to  the  willingness  of  our  contracton  to  lay  aside 
many  of  their  compeddve  constraints  for  the  good  of  the 
process.  A  successful  leadership  role  in  this  effort  could 
present  the  ATF  and  LH  contractors  follow-on  business 
opportunities  in  both  the  militaiy  and  commercial  markets. 

With  tliese  groundruies,  the  leadership  of  the  LH,  ATF 
and  A-12  programs  created  the  JIAWG  under  a  tri-service 
coordinate  charter  and  published  a  Joint  Integrated  Avionics 
Plan  (JIAP).  The  JIAP  was  first  published  in  March  1987,  and 
then  updated  in  March  1989,  both  times  under  the  signatures  of 
all  three  services' acquisition  executives.  The  JIAP  is  a  three 


part  document  presenting:  background  describing  the 
motivations  leading  to  the  JIAWG,  as  discussed  above;  a 
description  of  the  organization  called  JIAWG,  which  follows; 
and  information  on  joint  avionics  development  activities 
(opportunities  for  common  avionics  in  the  three  target 
programs,  the  ATF,  the  LH  and  the  A-12),  discussed  later. 

The  JIAP  is  the  implementation  plan  for  the  JIAWG  which, 
along  with  the  JIAWG  charter,  generally  establishes  direction 
and  guidance  for  the  group. 

Formed  in  1987,  the  JIAWG  has  been  focused  on 
matters  concerning  system  level  avionics  architecture  and 
module  commonality  associated  with  the  target  applications  of 
the  CAB,  the  LH,  ATF  and  A-12  (A-12  avionics  upgrade 
program).  Those  charged  with  planning  the  initiation, 
maturation  and  implementation  of  the  Common  Avionics 
Baseline  have  continually  pursued  the  broadest  most  robust 
definition  of  performance  requirements  essential  to  satisfying 
the  operational  needs  of  the  three  target  programs. 

The  significance  given  the  JIAWG  efforts  by  senior 
DOD  representatives  is  reflected  in  the  formal  organization  of 
the  group.  The  JIAWG  is  organized  to  respond  directly  to  the 
three  Service  Acquisition  Executives  through  the  affiliated 
Program  Executive  Officers  (PEO).  The  Service  Acquisition 
Executives  are  responsible  to  the  service  secretaries  to  establish 
acquisition  policy  and  to  ac-ure  weapon  system  development 
within  the  guidelines  set  forth  by  OSD  and  (Congress,  for  their 
programs.  The  PEO  is  the  single  authority  between  the 
individual  Program  Directors  and  the  Acquisition  Executive 
providing  development  guidance  and  management  overview. 
Figure  4  shows  the  relationship  of  the  JIAWG  to  the  formal 
service  acquisition  channels.  Although  the  Service  Acquisition 
Executives  are  effectively  the  final  decision  makers,  JIAWG 
issues  are  routinely  resolved  at  lower  levels  of  the 
organization,  precluding  the  need  to  directly  involve  these 
senior  representatives  except  for  the  most  significant  of 
politically  sensitive  issues.  Their  role  is  predominantly 
coordination  and  authorization  to  implement  decisions  that 
may  have  substantial  program  implications.  Much  the  same  is 
true  of  the  PEO  Executive  Committee. 

The  Joint  Programs  Managers  Group  (JPMG), 
composed  of  the  Directors  of  the  three  aircraft  programs, 
provides  specific  program  related  guidance  to  the  JIAWG  and 
repons  directly  to  the  PEO  Executive  Committee.  All  issues 
impacting  performance,  cost  or  schedule  are  addressed  by  the 
JPMG.  The  JPMG  sets  JIAWG  operating  policies  and 
considers  all  recommendations  for  implementation  of  the  CAB 
which  have  significant  cost  impacts.  The  JPMG  is  supported 
by  the  Industry  Executive  Council,  comprised  of  corporate 
executives  who  have  multiple  program  oversight  and  are 
directly  associated  with  top  level  business  management  of  the 
LH,  ATF  or  A-12.  The  Industry  Executive  Council  has  been 
instrumental  in  opening  conqietition  sensitive  doors  and  in 
assuring  ready  access  to  essential  performance  parameters. 

The  Steering  (Committee,  made  up  of  program  deputy 
directors,  is  responsible  for  dispute  resolution  and  tri-service 
coordination  of  JIAWG  Task  (jroup  recommendations.  An 
Industry  Advisory  Group,  made  up  of  senior  avionics 
contractor  engineering  representatives  involved  in  the  three 
weapon  system  programs,  provides  definitive  corporate 
positions  in  dispute  resolution  and  coordination  ensuring 
contractor  involvement  in  JIAWG  decisions.  Issues  involving 
proprietary  restrictions  and  competition  sensitivities  as  well  as 
basic  performance  capabilities  are  a  primary  focus  of  these 
groups 
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The  System  Integration  Committee  (SIC)  is  the 
working  level  government  and  industry  group  responsible  fm 
th'  efforts  of  developing  alternatives  for  an  Advanced 
A .  .onics  Architecture  (A’),  and  the  many  varied  common 
module  candidates  to  be  implemented  and  used  by  the  three 
programs  as  a  Common  Avionics  Baseline.  In  the  Air  Force, 
the  cffons  of  the  JIAWG,  at  and  below  the  SIC,  have  been 
principally  the  responsibility  of  the  former  ATF  Avionics 
Director,  Col  Mike  Borky,  until  recently  the  Air  Force  System 
Integration  Committee  representauve.  Much  of  the  JIAWG 
success  to  date  has  been  attributed  to  the  inspired  and 
insightful  leadership  of  Col  Borky.  More  will  be  said  of  the 
JIAWG  organization  Task  Groups  in  the  section  on  the  CAB 
Development  Process. 


THE  CAB  ARCHITECTURE 

The  Common  Avionics  Baseline  is  much  more  than  tlie 
lisung  of  specifications  for  development  of  tools,  architecture 
and  modules,  seen  in  Figure  5.  In  order  for  the  JIAWG 
structure  of  the  Common  A-/ionics  Baseline  to  work,  the  basic 
infrastructure  of  a  "genenc"  architecture  must  first  be  in  place. 
This  architecture  is  defined  in  the  advanced  avionics 
architecture  (A^)  standard  in  terms  of  physical  and  electrical 
characteristics  such  as  package  form  factor,  conneetorfs).  and 
power  supply  voltages;  environmental  requirements  such  as 
temperature,  vibration,  and  corrosion  atmospheres;  interfaces, 
especially  backplane  and  inter-rack  bus  protocols;  software 
engineering  standards  and  common  software  tools;  and  overall 
requirements  for  reliability,  maintainability,  and  supportability 
(RM&S).  The  basic  configuration  units  of  the  CAB  are  the 
haidware  line  replaceable  modules  (LRMs),  generally 
packaged  in  a  modified  Sfandard  Electronic  Module  -  Format 
E  (SEM-£j  and  reusable  software  packages  written  in  Ada. 
Individual  common  item  speciRcations  and  standards 
incorporate  the  appropriate  performance,  timing,  functional 
and  other  parameters  needed  to  complete  the  definition.  Thu 
CAB  is  fundamentally  a  collection  of  capabilities  which  when 
arranged,  adjusted  and  properly  matched  to  the  application, 
will  serve  as  the  processing  and,  potentially  in  the  future,  the 


sensing  elements  of  an  advanced  avionics  suite  Figure  6 
offers  a  general  structure,  or  orientation,  of  the  CAB  elements 
to  achieve  an  integrated  system  The  data  and  signal 
processing  capabilities  to  support  radar,  electronic  combat, 
communication/navigation/  identification,  conttol  and  display, 
stores  management,  general  processing,  etc.,  will  all  be 
available  within  the  current  CAB  in  the  form  of  common  data 
and  signal  processor  modules,  memory  modules,  interface 
modules,  and  power  supplies  modules,  etc. 

The  foundation  of  the  CAB  is  the  advanced  avionics 
architecture.  A’.  The  fundamental  principles  of  this 
architecture  are  that  it  accepts  standard  modules  (such  as  those 
just  mentioned)  which  are  interoperable  and  exchangable  in  a 
variety  of  applications;  it  meets  defined  performance  standards 
for  system  partitioning,  interconnects,  diagnostics  and 
.Initialization;  it  implements  a  presenbed  information  security 
capability;  it  accommodates  technology  insertion;  and  it  is 
re.idily  integrated  into  fighter  and  attack  helicopter  size 
aircraft. 


The  A^  is  a  derivative  of  the  PAVE  PILLAR 
architecture  that  evolved  in  the  early  80s.  As  the  A’  has 
evolved,  the  range  of  implementation  variables  has  gradually 
narrowed  The  fundamental  features  of  the  A’,  have  been 
reiined  and  adjusted  through  a  series  of  tradeoffs,  which  will 
le  discussed  later  in  this  paper.  Although  ihe  current  A’ 
standard  renciins  open-ended  to  some  degree  with  two  similar 
architectural  alicmatives,  which  will  also  be  discussed  later, 
both  alternatives  share  essential  characteristics.  As  suggested, 
the  A’  is  an  open  architecture  which  permits  interface  of  both 
16  and  32  BIT  data  processors,  flexible  mass  memory  and 
signal  processing  via  high  speed  fiber  optic  data  and  signal 
networKs.  The  A’  interface  to  radar,  electronic  combat  and 
other  sensors  is  via  point-to-point  high  speed  fiber  optic 
networks  with  more  conventional  Mn--STD-1553  busses  I 

available  for  less  time  stressing  functions  such  as  flight  control  | 

and  stores  management.  Other  features  include  a  test-  I 

maintenance  interface  (TM  bus)  to  support  background  fault  | 

monitoring,  reconfiguration  implementation  and  general  4 

maintenance.  While  much  of  the  A’  baseline  is  common  | 

between  the  two  A’  alternatives,  there  are  differences,  such  as  I 


JOINT  INTEGRATED  AVIONICS  WORKING  GROUP 
COMMON  AVIONICS  BASELINE 
JIAWG  CAB  in,  REV  1 


J87>01  Advanced  Avionics  Architecture  (A^)  StandaM 

J90*CNI^1  Integrated  Communication,  navigation.  Idcnttfication  System  Standard 

J87-G2A  Standard  Connector  Spcciricaiion 

J88*G2B  Standard  Module  SpcciHcation 

J88-G4  Configuration  Management  Plan 

J88*G6  Integrated  Logistics  Support  Standard 

J87-M1  Common  Avionics  Processor  -  16Bit(CAP>l6)Specincauon 

J83'M1  A  Input/Output  and  BuiU-in  Test  Interface  Description  (lOBID)  Six;ctrication 

J89-M1D  CAP-16  Instruction  Set  Architecture  Specifcation 

J88-M2D  Data  Processor  •  Common  Avionics  Processor*  32  Bit  (DP-CAP-32)  SpcciHcation 

J89*M2D]/2  32  Bit  Computer  Instruction  Set  Aimhitecture  Specification 

J89*M3  Extended  Memory  *3?  Bit  Specification 

J89-M4  Non-volatile  Bulk  Memory  Module  (NVBMM)  SpeciHcation 

J88*M5D  Data  Processor  High  Sp^  Data  Bus  Interface  Module  (HSDBIM)  Spccidcalion 

J88-M6D  Multiplex  Data  Bus  Interface  Module  (1553  BIM)  Specification 

J88*M7  General  Specidcau on  for  Power  Supply  (ot  Airbcmie,  Electronics  Specification 

J88'M7A  Airborne  Standard  Power  Supply,  50  amp  <PS-50)  Specification 

J88-M7B  Airborne  Standard  Power  Supply,  270  VDC  Input,  Multiple  Output,  Specification 

J88-M7C  Airborne  Standard  Power  Supply,  28  VDC,  Specidcation 

J87-N1  Module  Interconnect  E)ocumcnt 

J89-N1 A  IIAWG  Parallel  Intermodule  Bus  (JPMmjs)  Specification 

J89-N1B  JIAWG  Test  and  Mamicnancc  Bus  (JTM-bus)  Specification 

J89-NIC  Utility  Signals  Specification 

J88-N1F  UserConsole  Interface  Specidcation 

J90-N1H  UserConsole  Interface  Specification  for  32  Bit  Modules 

J88-N2  Linear  Token  Passing  Multiplex  E)ata  Bus  Protocol 

J89-S2  DOD-STD  2167A  System/Software  Engineenng  Information  Requirements  Concept  Paper 

J89-S3  SoRware  Engineenng  Environment  (SEE)  Specidcation 

J89-S4  Software  Engineering  Environment  (SEE)  Integration  Features  Concept  Paper 

J89-S5  Common  SEE  Life  Cycle  Support  Concept  Paper 

J89-S6  Tailored  DOD-Sn>-2167A  Rationale 

J89-S7  Software  Reuse  Concept  paper 

J89-S9  Software  Reuse  Domain  Analysis  Concqit  paper 

J90-S10  Module  lniuali2ation,  Test  and  Software  Interface  (MITSI)  Specidcation 

J89-SP-0I  Signal  Processor  Architecture  Specification 

JJ89-CH1  Optical  Disk  Functional  Spcctficatton 

I89-CH2  Data  Transfer  Units  Functional  Spccificauon 

J89-CH3  Airborne  Standard  Power  Supply  Specification 
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the  implementation  of  a  parallel  intermodule  (Pl-bus),  required 
by  only  one  of  the  alternatives.  The  detailed  functional 
descriptions  of  both  A’  altemaaves  are  contained  in  JIAWG 
standard  J87-01.  It  is  the  intent  of  those  involved  in  JIAWG  to 
achieve  a  single  advanced  avionics  architecture  during  the 
course  of  LH  and  ATF  full  scale  development.  The  ability  to 
achieve  this  will  be  dependent  on  the  success  of  the  LH/ATF 
commonality  working  group  (to  be  diseussed)  in  reconciling 
the  differing  architectural  demands  of  the  two  aircraft. 

A  series  of  draft  specifications  and  standards,  see 
Figure  5,  establishes  the  basis  for  form,  fit  and  function  (P) 
performance  capabilities  for  the  proposed  modules.  As 
examples  of  the  CAB  specifications,  extracts  outlining  the 
significant  features  of  the  common  standard  module,  the 
common  standard  power  supply  and  the  environmental 
requirements  for  all  modules  aie  provided  in  Figures  7,  8  and 
9,  respectively. 

In  addition  to  the  specifications  and  standards  for 
modules,  the  CAB  specification  set  addresses  interfaces 
(backplane,  buses,  protocols,  etc.);  physical  and  electrical 
charactenstics  (modified  SEM-E  form  factor,  connectors, 
power  supply  features,  environmental  requirements,  etc.); 
software  features  (software  engineering  environment,  reuse 
opportunities,  standard  language,  etc );  and  basic  supportabilily 
(ILS,  durability,  maintainability,  etc.).  The  combined 
application  of  the  necessary  elements  of  the  CAB  will  provide 
a  very  powerful  avionics  architecture  available  to  military  and 
commercial  users. 

As  with  the  A’  standard,  the  details  of  nearly  all  these 
module  standards  remain  to  be  resolved.  However,  a  specific 
process  to  accomplish  the  necessary  tradeoffs  and  maturation  is 
in  place.  Further,  although  the  JIAWG  CAB  efforts  have  been 
focused  almost  exclusively  on  core  processing  as  the  initial 
commonality  opportunity,  we  are  expanding  our  efforts  to 
pursue  pontons  of  the  mission  avionics  (radar,  electronic 
combat,  CNI,  etc.). 


CAB  DEVELOPMENT  PROCESS 

Many  different  Task  Groups  have  been  formed  to 
define  and  develop  preliminary  functional  requirements 
specifications  for  the  A^  and  common  modules,  see  Figure  10. 
All  Task  Groups  are  led  by  AF,  Army  and  Navy 
representatives  with  pafticipation  by  both  government  and 
contractor  engineers  and  managers.  At  this  level,  the  many 
compromises  necessary  to  satisfy  the  requirements  of  all 
participants  are  formulated.  As  can  be  inferred  from  the 
process  used  to  develop  common  specifications.  Figure  1 1,  the 
challengi  s  of  settling  on  a  final  specification  for  any  particular 
aspect  of  the  CAB  is  an  iterative  effort.  To  appreciate  the 
magnitude  and  complexity  of  this  task,  a  series  of  examples  is 
useful 

The  work  horse  of  the  CAB  is  the  32-bit  common 
standard  data  processing  element.  This  particular  module  is 
featured  in  the  implementation  of  every  avionics  function,  e.g. 
radar,  electronic  combat,  CNI.  controls  and  displays,  etc.,  see 
Figure  12.  Each  module  cluster  includes  at  least  one  32-bit 
standard  data  processing  element  Because  the  baseline 
architecture  offered  by  the  JIAWG  participating  contractors 
was  initially  that  of  their  preferred  avionics  implementation 
(one  from  each  LH,  ATF,  and  A-12  contractor),  the  32-bit 
processor  originally  consisted  of  several  general  definitions 
(interface,  throughput,  and  memory  definitions).  Thus,  the 


industry  and  government  inputs  for  the  initial  32-bit  data 
processor  specification  were  rather  broadly  and  loosely 
established.  One  challenge  was  a  possible  definition  of 
common  feamres  between  the  vanous  candidates.  Beyond 
that,  the  question  was  whether  or  not  compromises  could  be 
found  such  that  a  single  standard  specification  could  provide 
for  all  the  performance  and  capability  needed  to  .support  each 
user  without  such  a  severe  overhead  burden  as  to  make  the 
performance  and/or  cost  of  the  module  completely  inefficient. 
In  this  case,  the  process  shown  in  Figure  1 1  was  accomplished 
many,  many  times.  At  one  point,  frustration  nearly  prevailed 
in  the  form  of  a  forced  decision  on  one  specific 
implementation.  That,  however,  would  have  violated  one  of 
the  fundamental  principles  of  the  JIAWG  by  putting  at  least 
one  panicipating  contractor  at  a  serious  competitive 
disadvantage  In  this  case  the  Joint  Program  Managers  Group 
stepped  in  deciding  that  the  32-bit  data  processor  definitions 
would  also  include  two  alternatives,  thus  preserving  the 
competitive  nature  of  both  the  ATF  and  LH  efforts.  At  this 
writing,  there  is  strong  commonality  opportunity  between  pairs 
of  LH  and  ATF  architectures  and  32-bit  processor.  Once  full 
scale  development  contracts  are  awarded  for  both  programs, 
work  will  proceed  toward  a  single  common  s’andard  for  both 
the  A^  and  the  32-bit  processor. 

Another  example  of  the  JIAWG  specification  process 
involving  few  but  intensive  iterations  is  the  effort  to  establish  a 
set  of  design  physical  environments  for  each  module.  This 
particular  task  sounds  rather  straight  forward,  but  it  became 
substantially  complicated  with  the  insertion  of  the  Air  Force 
Avionics  Integrity  Program  (AVIP).  Rather  than  following  a 
traditional  path  of  setting  military  standard  environmental 
constraints,  for  thermal,  vibration,  acoustic  and 
electromagnetic,  the  AVIP  imposes  a  detailed  aircraft  to 
electronic  component  level  design  analysis  and  verification 
process  to  establish  and  impose  the  environmental  conditions 
more  likely  to  be  encountered  by  the  avionics  over  its  lifetime. 
This  represents  a  cultural  difference  between  Air  Force  and 
Navy  engineers.  In  this  case,  the  applicable  Task  Group  and 
the  Systems  Integration  Committee  evolved  a  compromise  that 
imposed  the  military  standards  desired  by  the  Navy,  as  a 
minimum,  with  the  Air  Force’s  AVIP  efforts  deriving  and 
imposing  platform  specific  requirements  when  they  exceed  the 
Navy's  military  standard  baseline.  Early  predictions  suggest 
the  differences  are  not  severe. 

A  final  example  of  this  process  is  one  that  after 
substantial  technical  activity  and  the  involved  efforts  of  the 
SIC,  the  Steering  Committee  and  the  JPMG  remains 
unresolved.  One  of  the  most  significant  issues  faced  by  the 
JIAWG  in  terms  of  potential  cost  and  performance 
implications  is  the  imposition  of  nuclear  Transient  Radiation 
Effects  on  Electronics  (TREE)  hardening  requirements.  This 
issue  could  impede  closure  on  a  final  set  of  draft  CAB 
specifications.  The  Army  and  the  Navy  require  hardening  of 
JIAWG  modules  for  nuclear  TREE,  based  on  LH  and  A- 1 2 
operational  requirements.  Simply  stated,  the  issue  revolves 
around  the  level  of  TREE  requirements  to  be  imposed.  It  is 
clear  that  any  TREE  requirement  will  add  cost.  The  teal  issue 
is  that  the  Army's  operational  community  is  faced  with  the 
potential  need  to  harden  their  avionics  at  levels  up  100  times 
more  stressing  than  either  the  Navy  or  the  Air  Force  are 
interested  in  dealing  with.  The  cost  implications  of  imposing 
TREE  requirements  for  such  levels  of  hardening  have  been 
established  to  be  very  significaiiL  It  will  be  very  difficult  to 
justify  this  cost,  especially  for  the  ATF  which  has  no  formal 
user  defined  operational  requirement  for  TREE  hardening. 

Such  issues  have  been  routinely  resolved  at  or  below 
the  System  Integration  Committee.  Because  of  the 


JOINT  INTEGRATED  AVIONICS  WORKING  GROUP 
ENVIRONMENTAL  REQUIREMENTS 
(DOCUMENT  J88-G2B) 


SCOPE;  All  modules  shall  be  in  accordance  with  the  requirements  specified 
in  the  JIAWG  Advanced  Avionics  Architecture  Standard  (J87-01) 


electrical  COiJFiGURATIOn:  When  a  module  Is  designed  in  a  new 
logic/technology  fartiiiy  that  duplicates  an  existing  module  function  in  a 
different  logic/technology  family,  the  new  module  shall  be  designed  such 
that  the  contact  assignments  in  the  new  module  are  identical  to  those  of 
the  existing  module  (J88-G2B1) 

MECHANICAL  CONFIGURATION:  The  basic  module  configuration  and 
dimensions  shall  conform  with  the  SEM-E  form  factor. 


CONDUCTION  COOLING:  The  module  shall  be  designed  to  be  conduction 
cooled  through  the  module  guide  ribs 

MODULE  CONSTRUCTION:  The  module  frame  shall  include  module  rib 
structures  and  Insertion/extraction  features 


MODULE  CONNECTOR:  The  module  connector  shall  be  In  accordance  with 
the  requirements  specified  In  J87-G2A 


FIGURE  7 


JOINT  INTEGRATED  AVIONICS  WORKING  GROUP 
ENVIRONMENTAL  REQUIREMENTS 
(DOCUMENT  J88-G2B) 


Scope:  Establishes  the  requirements  for  a  5.0/5.2  volt  (v),  50  ampere  (A) 
airborne  electronic  power  supply  in  a  Standard  Electronic  Moduie 
Format  -  E  (SEM-E) 


INPUT  POWER:  220v,  3PHASE,  400Hz  AC  or  270  vDC 


OUTPUT  POWER:  Nominal  5.0  vDC.  I'C  A  (Programmable  to  5.2  vDC) 

PARALLEL  OPERATION:  Meet  all ».  erformance  when  paralleled  with  up  to 
nine  common  power  supply  me  Jules 

PHYSICAL  CHARACTERISTICS:  1,5  Pounds,  SEM-E  Form  Factor,  J87-G2A 
Connector 


EFFICIENCY:  80%  @100%  Load 

BUILT-IN-TEST:  During  Power-up,  Continuous  Monitoring,  Maintenance 
Fault  Detecfion/lsolation  (Test  Maintenance  Bus  Interface) 

RELIABILITY:  20,000  HRS  MTBF  (To  be  revised  per  AVIP) 

\  PERFORMANCE  FEATURES:  (Defined  In  detail  in  specification)  / 

V _ ^ 
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JOINT  INTEGRATED  AVIONICS  WORKING  GROUP 
ENVIRONMENTAL  REQUIREMENTS 
(DOCUMENT  J88-G2B) 


STORAGE  TEMPERATURE:  -54  C  TO  +95  C 

OPERATING  TEMPERATURE:  -40  C  TO  +75  C  (30  Min  excursion  TO  +85  C) 

THERMAL  SHOCK  (non-operating):  -54  C  TO  +95  C 

HUMIDITY:  100%  operating 

SALT  FOG:  5%  Solution  @  35  C  for  96  HRS 

SHOCK  (Impact):  14  Drops  of  24  inches  to  concrete 

VIBRATION:  4  HRS  each  axis  sinewave  1.0  T0 1 .7  gs  (freq  dependent) 

165  Db  from  31.5  TO  8000  Hz  acoustic 
EMIC:  40  Db  case  shielding 

Conducted/Radiated  Emissions/Susceptiblllty  combined  Army/Navy/ 
Air  Force  requirements 

EMP/TREE:  Still  under  consideration 
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significance  of  this  TREE  issue,  it  is  in  the  hands  of  the  Joini 
Program  Managers  Group.  Because  of  the  significant  cost 
impacts  involved,  the  issue  may  come  to  a  decision  to  relax  the 
Army  requirement  or  incur  a  substantial  cost  addition  to  be 
bom  by  all  users  of  JIAWG  modules,  These  facts  are  being 
assessed  by  the  Army,  Navy  and  Air  Force  in  consideration  of 
their  individual  TREE  hardening  requirements  versus  the  cost 
of  TREE.  It  appears  the  Army  is  moving  toward  a 
compromise  that  would  relax  the  TREE  requirements  on  all 
but  safely  of  flight  electronics.  The  Navy's  position  is  also 
being  refined  at  this  time. 

These,  and  many  otlier  similar  challenges  have  been 
confronted  by  the  JIAWG.  In  every  case,  some  resolution  has 
been  achieved  to  permit  continued  movement  toward  a 
successful  Common  Avionics  Baseline. 


EVOLUTION  AND  STATUS 

The  JIAWG  has  established  a  schedule  for  the  release 
of  successive  versions  of  specifications  and  standards  as  the 
documents  mature  and  the  participating  weapon  system 
programs  proceed  through  their  phases  of  development.  The 
major  CAB  releases,  identified  as  CAB  I  through  V,  arc  as 
follows: 

CAB  1.  Released  in  June  1987  as  Version  1  of  the  A^. 
This  release  also  identified  existing  MIL  Specificauons  and 
Standards  to  be  incorporated  in  the  CAB.  CAB  1  served  to 
start  the  JIAWG  dialogue  and  establish  procedura'  and  policy 
guidelines. 

CAB  II:  Released  in  January  1989  as  Versions  1  and  2 
(CAB  IIA  and  IIB)  of  an  initial  set  of  CAB  documents,  plus 
documentabon  of  the  results  of  extensive  commonality 
assessments  aimed  at  identifying  areas  of  potential 
standardization 

CAB  III:  Released  in  1990  as  Version  3  of  the  CAB 
documents  and  made  available  for  incorporation  into  tbe  ATF 
and  LH  Full  Scale  Development  Requests  for  Proposal  and 
contacts.  Charactenstics  of  these  documents  include: 

Type  A  specification  format  defining  overall 
weapon  system  and  avionics  segment  functional  performance 
requirements. 

Defined  sufficiently  to  allow  contractual 
application  and  to  suppon  valid  contractor  assessment  of 
development  effort,  risk,  and  cost  of  incorporating  these 
capabilities  into  the  intended  design.  Some  technical  issues 
remain  open  pending  the  conclusion  of  the  LH  and  ATF  FSD 
activities. 

CAB  IV:  Scheduled  for  release  in  October  1993  as 
Version  4  CAB  documents.  These  will  be  in  the  form  or  final 
B-Specifications  (Prime  Item  Development  specifications),  and 
preliminary  C-Specifications  (product  function  fabneation 
specifications).  These  documents  will  be  available  subsequen' 
to  the  ATF  and  LH  Critical  Design  Reviews  (CDRs). 

CAB  V:  Scheduled  for  release  in  June  1998  as  Version 
5  documents.  These  will  be  complete  product  function  C- 
Specifications  representing  verified  and  quabfied  designs  ready 
for  piuduclion  implementation.  Additional  functional 
performance  siiecifications  can  be  expected  as  more  modules 
are  offered  as  JIAWG  candidates. 

As  mentioned  earlier,  the  JIAWG  has  made  excellent 
progress  overall,  including  areas  such  as  secunty  and  software 
reuse,  which  were  not  contemplated  in  the  original  JIAP.  All 


aerospace  pnme  contractors  involved  in  the  LH,  ATF,  and  A- 
12  efforts  have  signed  a  memorandum  of  agreement  agreeing 
to  support  the  JIAWG  and  they  have  cooperated  fully  in 
sharing  information  and  in  working  on  CAB  documents. 
Commonality  assessments  for  all  avionics  areas  have  been 
completed  identifying  the  most  likely  common  modules  and 
have  allowed  work  to  be  focused  on  areas  of  highest  potential 
payoff.  In  a  number  of  areas  significant  compromises  are 
leading  to  final  versions  of  CAB  documents  well  ahead  of 
schedule. 

CAB  III  contains  most  of  the  "generic"  documents 
re  uired  for  LH  and  ATF  contracts;  as  mentioned,  a  few  items 
will  remain  to  be  resolved  in  the  two  FSD  programs.  The 
CAB  III  document  set  will  bi,  refined  greatly  immediately 
following  LH  and  ATF  source  selections  as  the  design 
alternatives  of  the  losing  contractors  are  removed  from  further 
consideration.  Also,  in  areas  such  as  Electronics  Combat  (EC), 
Communicalion/Navigalion/ldentification  (CNI),  radar  and 
core  signal  processing,  the  JIAWG  is  currently  dealing  with 
equally  valid,  but  mutually  incompatible,  design  approaches  by 
competing  contractors  The  FSD  contractor  selections  will 
effectively  narrow  these  alternatives  as  well.  Since 
specifications  for  all  contending  approaches  will  already  exist 
as  outputs  of  the  recently  completed  LH  and  ATF 
DemonstraiionA^alidalion  woric,  the  necessary  documents  can 
be  added  to  the  CAB  relatively  easily.  Future  weapon  system 
programs  will  have  available  a  mature  and  validate  common 
avionics  inventory  as  defined  in  CAB  V  documents  and  will  be 
able  to  incorporate  those  CAB  items  identified  as  required  for 
the  necessary  functionality  and  as  appropriate,  through  their 
own  cosi/benefit  analyses. 


ATF/LH/A.12  INTERFACE 

As  discussed  earlier,  the  LH  and  ATF  are  the  pacing 
JIAWG  related  development  programs.  Both  programs  are 
working  lOward  evolving  both  a  common  avionics  architectural 
baseline  and  as  many  common  modules  as  practical.  The 
performance  demands  of  a  helicopter  program  versus  a  high 
performance  fighter  aircraft  have  made  progress  rather  slow 
and  painful;  however,  as  discussed  earlier,  significant  progress 
has  been  made  and  significant  commonality  opportunities  are 
available.  The  ATF  and  LH  Requests  for  Proposal  require  the 
winning  contractors  to  work  together  to  mature  JIAWG 
specifications  and  demonstrate  module  level  interopcrablity 
and  exchangeability.  These  efforts  are  expected  to  result  in 
venfication  of  the  suitability  of  the  A’  to  support  widely 
diverse  applications  and  in  the  maturing  of  a  set  of  common 
module  specifications,  culminating  in  module  level 
interoperability  demonstrations  and  validated  specifications, 
CAB  V,  Version  5. 

At  this  point,  the  ATF  FSD  RFP  mandates  the 
application  of  CAB  specifications  to  set  the  opportunities  for 
common  LH/ATF  avionics.  The  JIAWG's  focus  is  directed  to 
refining  the  current  preliminary  CAB,  establishing  the  essential 
efforts  of  our  FSD  contractor  in  continuing  the  JIAWG  efforts, 
and  in  implementing  the  LH/ATF  commonality  demonstration 
plans.  This  is  being  accomplished  in  both  the  IH  and  ATF 
programs  by  including  all  draft  JIAWG  CAB  III  specifications 
by  reference  in  the  top  level  Weapon  System  Specification  and 
by  requiring  the  offerors  to  define  their  process  for  further 
maturing  these  specifications  during  FSD.  Also,  both 
programs  are  requiring  the  offerors  to  define  a  working 
relationship  between  themselves  through  which  commonality 
opjwrtunities  will  be  further  refined  and  matured.  This ’s  to  be 
managed  by  an  LH-ATF  commonality  working  group  made  up 
of  contractor  and  government  engineers  and  managers. 


Considering  the  premise  of  JIAWG  as  evolving  a  common 
avionics  architecture  and  a  set  of  common  modules  from  which 
future  avionics  suites  could  be  constructed,  another  FSD  task 
will  be  joint  verification  of  interoperability  and,  if  possible, 
exchangeability  of  avionics  modules  between  ATF  and  LH.  It 
IS  the  responsibility  of  the  ATF/LH  programs  offices  to  jointly 
validate  CAB  HI  specifications  and  produce  the  CAB  IV  and  V 
specification  versions.  As  mentioned,  CAB  IV  specifications 
will  be  available  at  a  point  when  the  architecture  and  module 
designs  are  considered  capable  of  achieving  the  ATF  and  LH 
program  requirements,  around  October  1993.  The  level  of 
commonality  of  the  JIAWG  CAB  IV  will  be  dependent  upon 
the  ability  of  both  programs  to  achieve  their  individual 
requirements  under  the  constraints  of  commonality.  In  terms 
of  opportunity,  we  believe  the  number  of  common  modules 
could  be  as  high  as  70  to  80,  if  sensor  modules  supporting 
radar,  electronic  combat,  CNl,  etc  ,  can  be  baselined.  A  mote 
conservative  view  based  on  our  primary  focus  on  core 
processing  commonality  is  that  approximately  20  modules 
making  up  a  common  core  processing  capability  could 
reasonably  be  developed  as  ATF/LH  common  items.  These  20 
some  common  modules  would  equate  to  a  validated  integrated 
architecture  and  a  fully  capable  integrated  processing  system. 
The  final  number  is  very  ^pendent  on  the  ability  of  the 
common  module  to  satisfy  both  programs'  performance 
requirements  at  an  acceptable  cost.  Whatever  the  initial 
baseline  may  be,  it  is  clear  that  the  future  of  advanced  avionics 
IS  in  the  direction  of  this  Common  Avionics  Baseline. 

Beyond  this  joint  commonality  baseline,  all  the 
avionics  modules  of  either  the  ATF,  or  the  LH,  or  both, 
development  programs  will  be  available  to  future  programs,  in 
effect,  offering  the  potential  for  a  much  broader  module  set. 

As  discussed  earlier,  commonality  initiatives  will  be  pursued 
aggressively,  but  with  a  healthy  regard  for  both  the  cost  and 
performance  implications.  It  is  the  intent  of  the  ATF  and  LH 
System  Program  Offices  to  foster  opportunity  for  common 
avionics  within  the  constraints  of  assuring  the  weapon  systems 
are  capable  of  meeting  the  needs  of  their  customers.  It  is  the 
intent  of  the  JIAWG  to  assure  that  all  opponunities  arising 
from  the  ATF  and  LH  program  efforts  are  made  available  to 
potential  users,  see  Figure  13.  In  this  manner,  the  goals  of  the 
JIAWG,  satisfying  the  Congress,  OSD  and  the  Army,  Air 
Force  and  Navy  can  be  achieved. 


SUMMARY: 

The  JIAWG  CAB  is  expected  to  have  rnormous 
influence  on  the  entire  next  generation  of  avionic  systems.  It  is 
imperative  that  good  standardization  decisions,  bas^  on  a 
credible  data  base  of  design,  test,  and  analysis,  be  used  as  the 
basis  for  CAB  definition.  Premature  publication  of 
specifications  and  standards  whose  content  is  not  well  founded 
and  likely  to  change  could  cause  resources  to  be  wasted  by  the 
industry  and  could  fatally  undermine  the  credibility  of  this 
DOO  avionics  commonality  thrust.  As  noted  earlier,  the  CAB 
development  is  concurrent  with  the  development  phases  of  the 
LH  and  AIF  programs  from  which  the  data  need^  to  close 
remaining  technical  issues  will  be  derived.  The  JIAWG 
process  provides  a  systematic  way  to  define  technical  issues 
and  alternative  solutions  and  to  draw  on  all  valid  data  sources 
in  establishing  the  preferred  resolution  of  each  issue.  This 
process  will  be  tightly  coordinated  with  the  weapon  system 
programs  to  ensure  specifications  and  standards  incorporate 
adequate  and  current  data  from  analysis  and  testing  to 
complete  each  version  of  the  CAB  as  part  of  planned  weapon 
system  development  milestones. 


As  the  JIAWG  CAB  matures,  specific  procedures  for 
document  maintenance  and  CAB  update  configuration  control 
will  evolve.  Several  proposals  are  being  considered,  however, 
decisions  on  the  long  term  of  JIAWG  are  still  being 
considered.  In  the  immediate  future,  anyone  wishing 
information  on  the  JIAWG  or  the  Common  Avionics  Baseline 
should  contact: 

United  States  Companies  -  Contact: 

VEDA,  Inc.. 

5200  Springfield  Pike 
Dayton,  OH  45431 
Attention:  JIAWO/Jackie 

Lane 


Foreign  Companies  -  Request  information  through 
country  embassy: 


ASD/YF 


OK  45433 


Wnght-Patterson  AFB, 
Attention:  JIAWG  Point 


of  Contact 
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Abstract 

Flexibility,  survivability,  availability  and  cost  of 
ownership  of  modem  aeronautical  weapons 
systems  increasingly  rely  upon  its  avionic 
systems  and  the  capabilities  offered  by  advan¬ 
ced  sensors,  processors  and  system  software. 
This  especially  holds  true  with  regard  to 
upgrade  programmes  mostly  driven  by  the 
increasingly  sophisticated  threat  and  advances 
in  the  avionics  field. 

The  limited  ressources  of  the  European  coun¬ 
tries  as  well  as  the  rising  cost  of  avionics  equip¬ 
ment  and  software  need  innovative  approaches 
beyond  already  established  joint  European 
defense  projects  in  order  to  keep  weapons 
systems  affordable.  This  paper  is  focussed  on 
equipment  standards  that  allow  technology 
growth,  maximize  competition  and  promote 
reusability  of  designs,  on  the  avionics  system 
software  evolution  and  on  experiences  gained  in 
german  TORNADO  and  F-4F  upgrade  pro¬ 
grammes.  Indications  with  regard  to  possible 
future  upgrade  programmes  will  also  be  given. 

As  far  as  standardization  is  concerned,  this 
paper  will  present  an  overview  of  objectives 
and  status  of  actual  german  research  and  deve¬ 
lopment  projects  generally  known  under  the 
notion  "Modular  Avionics"  and  their 
relationship  to  international  initiatives.  Growing 
system  software  complexity  as  well  as  rising 
software  problems  and  cost  have  forced  soft¬ 
ware  development  into  rigid  development 
methods,  high  order  languages  and  towards 
increasing  standardization.  This  trend  is  high¬ 
lighted  on  the  basis  of  the  above  mentioned  and 
new  piogrammes,  where  the  close  coupling 
between  system  functions,  system  performance 
and  real  time  mission  software  can  be  observec 
very  prominently. 


1.  Introduction 


The  introduction  of  digital  avionics  based  upon 
freely  programmable  embedded  and  distributed 
real  time  computer  systems  into  military  fighter 
aircraft,  the  accompanying  transition  from  elec¬ 
tromechanical  to  software-intensive  systems  as 
well  as  the  current  trends  towards  integrated 
avionic  system  architectures  have  provided  new 
levels  of  capability,  flexibility  and  availability 
of  flying  weapon  systems.  System  functions  and 
system  performance  are  tightly  coupled  to  real 
time  mission  software  offering  different  modes 
and  capabilities  for  various  missions  and  increa¬ 
singly  sophisticated  threat  environments. 

The  computing  capacity  of  the  Electronic  Com¬ 
bat  Reconnaissance  (ECR)  Tornado  for  exam¬ 
ple,  now  in  delivery  to  the  German  Air  Force 
increased  considerably  compared  to  the  basic 
Tornado  aircraft  within  4  years:  The  number  of 
on  aircraft  loadable  computers  from  1  to  6  and 
their  memory  from  128  K  words  to  nearly  3000 
K  words.  3  of  the  6  computers  are  mission 
computers  programmed  by  MBB  as  prime  con¬ 
tractor  for  this  aircraft. 

Obviously  evolutions  of  this  magnitude  are  no 
longer  only  quantitative  but  also  qualitative  in 
nature  since  they  lead  to  a  considerable  increase 
of  the  complexity  of  me  avionic  systems  and  the 
development  processes  that  finally  provide 
those  systems.  Steadily  rising  costs  and  deve¬ 
lopment  time  frames  for  avionic  equipment  and 
software  reflect  these  trends;  some  30%  of  the 
flyaway  costs  of  current  military  fighter  aircraft 
are  spent  for  avionics. 

The  transition  from  loosely  coupled  or  stand 
alone  "black  boxes"  to  increasingly  integrated 
networks  of  avionic  subsystems  held  together 
by  avicnic  busses  and  real  time  mission  soft¬ 
ware  for  information  exchange  brought  also 
new  experiences  with  regard  to  system  and 
software  development  methodologies.  As  far  as 
software  development  is  concerned,  budget 
overruns,  missed  schedules  and  unrealistic  plan¬ 
ning  are  common  exfreriences  placing  the  costs 
for  avionics  systems  integration  and  acquisition 
under  critical  consideration. 


The  cost  issues  mentioned  are  of  additional 
importance  in  tlie  Europe  of  today  where  the 
Soviet  threat  has  virtually  disappeared.  Nevert¬ 
heless  a  potential  capability  and  the  fact  that  the 
Soviet  Union  is  and  will  be  a  superpower 
remains  and  there  is  a  common  understanding 
amongst  the  European  nations  that  it  is  essential 
to  maintain  a  coherent  defense  posture  for  the 
foreseable  future.  In  addition  the  war  at  the 
Persian  Gulf  has  prompted  new  conflict  scena¬ 
rios  that  will  lead  to  a  reevaluation  of  force 
stractures  and  missions. 

The  changes  in  the  nature  of  risks  and  threats 
(e.g.  new  threats  with  "western"  equipment, 
new  climatic  environments,  new  logistic 
aspects)  and  more  emphasis  on  mobility,  flexi¬ 
bility  and  reconnaissance  will  put  new  require¬ 
ments  on  existing  and  new  weapon  systems  and 
in  turn  on  avionics  systems.  But  these 
requirements  will  have  to  be  fulfilled  with 
shrinking  budgets  since  the  end  of  the  cold  war 
spurs  the  payment  of  "peace  dividends"  in  the 
western  democracies  and  the  member  nations  of 
NATO.  Besides  budget  reductions,  less  flying 
hours,  less  tolerance  to  noise  and  accidents  in 
the  dense  populated  Europe,  less  time  and  areas 
for  training  and  the  complexity  of  modem  wea¬ 
pon  systems  and  their  man-machine-interfaces 
impose  an  additional  burden  to  the  military 
forces  and  their  tasks. 

Based  upon  the  trends  mentioned  above  the  fol¬ 
lowing  sections  of  this  lecture  will  focus  on  the 
following  topics: 

-  Predictable  consequences  from  reduced  ten¬ 
sions  in  central  Europe,  changing  threat  sce¬ 
narios  and  new  emerging  needs 

-  Experiences  and  trends  related  to  avionic 
system  software  development  and  integration 

-  New  avionic  architectures  and  their  potential 
applications 

-  Possibilities  for  future  upgrade  programs. 


2.  Emerging  needs  in  the  1990’s 


'fhe  European  strategic,  industrial  and  economic 
situation  is  changing  rapidly  and  profondly.  The 
main  driving  factors  are  the  disintegration  of  the 
Warsaw  Pact  and  the  diminishing  Soviet  Threat 
in  Central  Europe,  the  integration  of  the  Euro¬ 
pean  economy  towards  a  single  European  mar¬ 
ket  in  1993  and  the  reunification  of  Germany. 
As  far  as  the  German  Armed  Forces  are 
concerned  there  are  already  visible  impacts  of 
the  new  environment: 

-  The  number  of  personnel  will  be  reduced  to 
370  000  up  to  1995  and  the  time  to  serve  in 
the  German  Armed  Forces  decreased  already 
from  18  to  12  months.  Therefore  failure-free 


performance  of  the  weapon  systems,  reliabi¬ 
lity  and  maint.-inability  together  with  more 
sophisticated  on  board  check  out  and 
monitoring  systems  for  the  avionics  systems 
will  gain  in  importance.  This  will  also  hold 
true  for  more  automated  test  equipment  on 
ground. 

-  Budget  reductions  are  already  under  way  and 
may  become  substantial  in  the  next  years. 

This  will  affect  the  affordability  of  advanced 
avionics  systems  if  no  measures  are  taken  to 
reduce  the  eosts  of  development  and  produc¬ 
tion.  More  emphasis  will  be  given  to  life 
cycle  costs  and  in  especially  to  the  operating 
costs  since  they  make  up  the  major  portion  of 
the  life  cycle  costs.  These  factors  promote  the 
reusability  of  designs,  productivity  improve¬ 
ments  in  the  area  of  software  development, 
common  developments  with  longer 
production  runs,  the  use  of  commercial  parts 
and  equipments  wherever  possible  and  again 
maintainability  and  reliability. 

-  The  German  Air  Force  has  taken  over  the 
responsibility  for  tlie  former  East  Gennany  on 
a  national  basis.  Taking  the  reduction  of  the 
armed  forces  into  account  fewer  forces  will 
be  available  to  cover  larger  areas  of  interest. 

Air  defense  fighters  will  be  more  important 
since  surface-to-air  missiles  might  not  be  able 
to  cope  with  the  new  situation.  Since  the 
number  of  combat  crews  might  be  reduced 
due  to  towered  states  of  readiness  and  since 
smaller  forces  lead  to  heavier  reliance  on 
reserves,  encreased  reconnaissance  and  intel¬ 
ligence  capabilities  seem  to  be  necessary. 


Besides  these  most  obvious  changes  there  are 
additional  factors  to  be  considered.  As  new 
threat  scenarios  emerge,  more  flexibility,  mobi¬ 
lity  and  the  capability  to  use  the  already  existing 
weapon  systems  to  the  maximum  extent 
possible  become  more  significant. 


Upgrade  programs  of  existing  weapon  plat¬ 
forms  can  provide  cost  effective  solutions  in 
this  regard.  The  primary  targets  for 
improvements  t^ing  into  account  the  latest 
advancements  in  the  avionics  field  are  the  man- 
nidchine  interface  (Cockpit),  the  mission  com¬ 
puters  in  order  to  obtain  more  throughput  and 
new  capabilities  like  threat  management, 
advanced  mission  planning  and  higher  degrees 
of  automation  of  many  functions  as  well  as  the 
capability  to  perform  various  complex  missions 
under  adverse  ECM  and  weather  conditions. 
Higher  degrees  of  automation  and  improve¬ 
ments  of  the  representation  of  the  information 
to  the  crew  to  provide  higher  levels  of  situation 
awareness  are  also  necessary  to  cope  with  redu¬ 
ced  training  time  and  space. 

These  trends  are  augmented  by  the  growing 
integration  of  the  avionics  systems  into  larger 


command,  control  and  communication  net¬ 
works. 

Therefore  crew  displays  will  have  to  contain 
information  rather  than  data,  adding  graphics, 
colour  and  other  visible  and  audible  cues  in 
order  to  provide  a  precise,  rapid  response  with 
the  lowest  false  alarm  rate. 


In  order  to  be  cost  effective  new  approaches  are 
sought  in  Europe  towards  common  develop¬ 
ment  programs.  In  the  course  of  the  creation  of 
a  single  common  market  1993  the  defense 
industry  will  probably  be  seen  in  less  national 
terms.  New  alliances  between  aerospace  firms 
(e.g.  DASA  in  Germany,  Airitalia  and  Selenia 
in  Italy)  form  the  basis  for  future  European 
ventures.  There  will  be  no  "Fortress  Europe" 
but  stronger  European  competitors  as  well  as 
perspectives  towards  an  "European  Aerospace 
Company"  in  the  future. 

There  is  also  a  growing  tendency  towards  com¬ 
mon  European  research  programs  aiming  at 
more  effective  use  of  government  funds  for 
research  and  development. 

An  example  is  the  Independent  European  Pro¬ 
gramme  Group  (lEPG),  founded  in  in  1976  to 
provide  a  European  forum  independant  of 
NATO  for  discussion  of  defence  equipment 
programs,  research  and  technology  and  the  har¬ 
monization  of  requirements.  MBB’s  participa¬ 
tion  in  these  programs  will  be  discussed  later  in 
this  lecture. 


3.  Avionics  Systems  Software  Development 


In  the  last  few  years  MBB  has  been  awarded 
major  system  update  and  development  contracts 
for  military  aircraft: 

-  F-4F 

Improved  Combat  Efficiency  Progmm: 

This  Program  basically  contains  the  integra¬ 
tion  of  a  new  fire  control  system  (AN/APG 
6.i  radar,  new  mission  computer  as  well  as 
new  air  data  computer  and  inertial  navigation 
systems)  and  the  AMRAAM  missile  into  the 
F-4F  flown  by  the  German  Air  Force 

-  The  integration  of  the  HARM  missile  into  the 
Interdiction  Strike  (IDS)  Tornado 

-  The  development  of  the  Electronic  Combat 
and  Reconnaissance  (ECR)  Tornado  variant 
for  tactical  reconnaissance,  surveillance, 
coordinated  recce/attack  operations  as  well  as 
electronic  combat  including  suppression  of 
enemy  air  defences  and  counter  C 


Key  elements  for  these  missions  are  new, 
advanced  infrared  imaging  and  emitter  loca¬ 
tor  systems  and  appropriate  mission  software 
offering  a  variety  of  mission  related  functions 
and  modes. 


These  update  /  modification  programs  and 
MBB’s  participation  in  the  European  Fighter 
Aircraft  (EFA)  program  have  clearly  shown  that 
from  the  point  of  view  of  an  aircraft  company 
avionics  system  integration  basically  means 
avionics  system  software  development  and  inte¬ 
gration. 

Mission  related  software  is  no  longer  just  one 
part  of  the  system  -  it  is  the  system.  System 
software  puts  together  the  various  subsystems 
and  equipments  developed  by  independent  sub¬ 
contractors  and  provides  essential,  increasingly 
automated  functions  as  navigation,  fire  control 
and  situation  assessment. 


Early  software  quality  problems  lead  to  the 
conclusion  that  the  time  frames  to  complete  a 
new  software  load  within  acceptable  quality 
brackets  have  been  grossly  underestimated.  It  is 
interesting  to  note  however,  that  the  amount  of 
time  needed  for  coding  and  testing  could  be 
predicted  fairly  accurately,  whereas  the  time 
needed  to  establish  firm,  unambiguous  software 
requirements  and  to  remove  the  remaining 
errors  had  not  been  taken  into  account  appro¬ 
priately.  The  main  reasons  were: 

-  the  lack  of  a  consistent  methodology  for 
system  and  system  software  development  that 
is  able  to  cope  with  larger  development 
and/or  update  programs  and  to  take  the  neces¬ 
sary  error  correction  cycles  into  account 

-  very  tight  schedules  and  the  associated  ten¬ 
dency  to  leave  the  necessary  requirement  refi¬ 
nements  for  the  following  phases 

-  unefficient  standardization  with  regard  to 
software  languages,  software  development 
environments  and  -processor  architectures 

-  the  difficulty  to  cope  with  software  require¬ 
ments  that  are  ever  changing  due  to  inadequa¬ 
tely  defined,  changing  or  misinterpreted  user 
requirements  and  the  fact  that  software 
requirements  also  need  maturity  times  in 
order  to  provide  the  required  levels  of  consi¬ 
stency,  completeness  and  understandability 
for  software  development  teams  mote  distant 
from  the  system  context 

-  the  fact  that  there  ate  cases  wnere  the  soft¬ 
ware  requirements  can’t  be  implemented  in 
the  proposed  form  due  to  hardware  or  system 
constraints. 

The  cutient  tendencies  to  place  fixed  price  con¬ 
tracts  upon  softwaie  development  and  to  reduce 
the  time  fiames  from  software  requirements 
specification  to  software  delivery  represent 
additional  new  challenges.  Fixed  pnee  contracts 
contain  the  risk  to  deliver  software  products 
with  marginal  performance  md  quality  and  the¬ 
refore  preprogrammed  conflicts  with  the  final 
user.  In  onJer  to  avoid  these  risks,  system  and 
software  development  concepts  with  built-in 
quality  considerations  are  sought.  The  first  step 
towards  this  goal  is  the  introduction  of  formal 
mles  and  stnictures  comparable  to  other  engi- 
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neering  disciplines.  Provided  that  the  basic  pro¬ 
cesses  leading  to  software  requirement 
specifications  and  the  software  itself  are 
completely  understood,  appropriate  tools 
aiming  at  the  automation  of  the  software  requi¬ 
rements  specification  task  can  be  very  helpful. 


3.1  System  Development 


MBB  took  several  measures  to  improve  the 
situation  with  regard  to  software  quality  and 
delivery  schedules.  First  we  introduced  a  more 
rigid  methodology  of  designing  complete  air¬ 
craft  systems.  It  had  to  be  applicable  for  diffe¬ 
rent  programs  without  major  changes,  it  had  to 
support  all  phases  of  system  development  and  it 
had  to  assure  that  the  interfaces  between  system 
engineering  groups  and  software  development 
groups  were  well  defined.  The  methodology 
had  to  allow  for  iterations  in  specific  phases,  for 
a  certain  amount  of  requirement  changes  during 
design  and  for  the  fixing  of  software  bugs  wit¬ 
hin  defined  update  cycles,  nevertheless  assuring 
proper  completion  of  each  phase. 

The  methodology  adapted  is  closely  related  to 
DOD  Std.  2167  but  has  been  amended  by 
equipment  development  and  some  other  phases 
to  cover  the  complete  avionics  system  develop¬ 
ment  process. 

For  the  purpose  of  this  lecture  it  seems  suffi¬ 
cient  to  discuss  the  main  features  of  this  deve¬ 
lopment  methodology  on  the  basis  of  the 
generic,  underlying  development  model 
depicted  in  Fig.  1.  There  are  three  distinct  pha¬ 
ses  starting  from  the  operational  needs  of  the 
customer  and  leading  to  the  final  avionics 
system  or  system  update:  System  definition, 
system  development  and  system  testing.  Each 
phase  is  subdivided  in  different  steps  concluded 
with  defined  development  results  and  subject  to 
various  reviews  and  audits.  It  is  important  to 
note  that  all  planning  for  new  projects  is  based 
upon  this  development  model.  The  specific  pro¬ 
ject  plans  then  allow  for  predefined,  cyclic  ite¬ 
rations  in  order  to  remove  residual  errors. 

The  system  definition  phase  leads  to  equipment, 
software  and  system  rt^uirement  specifications 
and  is  the  foundation  of  the  full  scale  develop¬ 
ment  process  afterwards.  Since  software  needs 
long  lead  times  it  is  important  to  consider  the 
impacts  of  new  mission  related  functions  on 
mission  software  ve^  early  in  the  design  pro¬ 
cess.  Currently  mission  software  resides  in  dis¬ 
tributed  computers;  therefore  the  development 
model  provides  for  a  system  software 
specification  describing  the  functionality  of  the 
various  mission  computers  as  a  whole.  User 
requirements  should  be  as  explicitly  as  possible. 


i.e.  in  terms  of  clearly  .stated  mission  objectives. 
The  design  process  however  should  allow  for 
some  requirements  creep  and  flexibility  by  the 
basic  architecniral  concept  and  hardware  and 
software  partitioning. 

This  also  refers  to  bus  loading  and  computer 
sizing;  the  design  should  have  future  changes  in 
mind  rather  than  absolute  efficiency. 

Avionics  system  testing  comprises  software, 
equipment  and  system/on  aircraft  testing  and  is 
very  expensive  in  terms  of  time,  people  and 
facilities  involved.  In  order  to  streainline  this 
process  and  to  optimize  the  use  of  the  available 
facilities  a  specific  approach  to  system  software 
testing  has  been  devised.  There  are  four  sepa¬ 
rate  test  stages:  Stage  A  testing  investigates 
autonomous  software  functions  or  operational 
flight  programs  testing  the  complete  software 
product  (CSCl)  residing  in  one  individual  com¬ 
puter  and  is  concentrated  on  showing  that  the 
implemented  software  satisfies  its  specified 
functional  and  perfomiance  requirements. 

Stage  A  testing  also  refers  to  hardware  tests 
where  the  hardware  /  software  functions  of  sin¬ 
gle  equipments  are  demonstrated. 

Stage  B  or  partial  integration  testing  is  related 
to  tests  that  will  be  performed  using  all  compu¬ 
ters,  all  software  and  all  interconnections  of  the 
computing  system  to  assure  that  not  only  single 
computer  programs  but  also  the  system  software 
and  the  cooperative  functions  of  the  system  as  ^ 
whole  will  perform  as  specified. 

Stage  C  or  system  integration  testing  covers 
hardware  /  software  integration,  subsystem  and 
system  testing  and  leads  to  a  flight  test  release 
of  the  whole  system.  Finally  flight  or  Stage  D 
testing  is  performed  in  order  to  validate  the 
system  performance  against  the  system  specifi¬ 
cation  in  tile  real  environment. 

This  testing  philosophy  offers  a  high  degree  of 
visibility  to  the  final  user  and  allows  for  quick 
tum  around  times  between  software  error  detec¬ 
tion  and  correction.  Most  errors  are  found 
during  early  test  phases  where  the  costs  for 
testing  and  recoding  are  relatively  low.  Cur¬ 
rently  only  about  5%  of  all  confirmed  errors  are 
based  upon  flight  test  results. 

Since  user  expectations  are  high,  but  require¬ 
ments  quite  often  not  clearly  stated,  there  is  a 
preprogrammed  conflict  situation  at  the  end  of 
the  development  process  where  early  visibility 
and  operational  evaluation  can  be  very  helpful. 
This  e.specially  holds  true  under  the  growing 
number  of  fixed  price  contracts. 

Within  smaller  projects  involving  smaller  engi¬ 
neering  groups  and  therefore  less  communica¬ 
tion  overfiead  deviations  from  the  "waterfall" 
model  (1)  underlying  DOD  STD  2167  have 
been  tried.  One  example  is  evolutionary  deve¬ 
lopment  (2),  i.e.  a  sequence  of  development 
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cycles.  During  each  phase  refinements  of 
requirements  and  software  are  taking  place  with 
the  final  user  actively  involved. 

This  approach  assumes,  that  requirements  can’t 
be  completely  defined  at  the  beginning  of  a 
project  and  that  they  change  during  the  rest  of 
system  development  due  to  a  growing  under¬ 
standing  of  the  real  needs  of  the  user. 

The  research  and  development  project  chosen  in 
order  to  demonstrate  this  approach  has  been 
considered  to  be  very  successful.  It  has  been 
developed  within  budget  and  within  the  time 
frame  scheduled  and  the  required  functions  met 
the  user  requirements. 

This  project  indicates  that  a  single  software 
requirements  phase  leading  to  firm  require¬ 
ments  in  one  step  is  rather  unrealistic.  Software 
requirements  cycles  supported  by  the 
prototyping  approaches  to  be  described  below 
seem  to  offer  greater  advantages. 


3.2  Tools  and  Standards 


Rigorous  configuration  control  and  tool  support 
were  other  measures  taken  towards  a  disciplined 
approach  to  software  development  and  in  order 
to  improve  productivity.  Fig.  2  gives  an  over¬ 
view  in  this  regard.  Tools  can  help  to  avoid  that 


bugs  are  getting  in  the  software;  if  they  do  get 
in,  to  find  them  as  soon  as  possible  and  finally 
to  make  maintenance  easier.  Since  configura¬ 
tion  control  and  the  application  of  software 
development  tools  are  current  practice  today 
and  not  the  main  objective  of  this  lecture  the 
focus  in  the  following  is  on  experiences  made 
and  recommendations  for  the  future. 

MBB  as  well  as  other  leading  aircraft  manufac¬ 
turers  in  Europe  are  heavily  involved  in  interna¬ 
tional  programs  like  Tornado  or  EFA.  Part  of 
the  work  is  carried  out  in  international, 
centralized  teams;  the  other  part  is  subdivided 
into  work  packages  for  the  participating  compa¬ 
nies.  In  order  that  this  workshare  is  successful, 
an  international  coordination  body  has  to  be 
established  and  the  interfaces  have  to  be  clearly 
defined.  For  the  transition  from  software  requi¬ 
rements  to  software  design  a  centralized  inter¬ 
national  engineering  team  has  to  collect  all 
software  requirements  to  harmonize  them  and  to 
define  the  ba.seline  for  further  work.  This  also 
applies  for  the  selection  of  appropriate  tools  and 
development  environments.  It  is  this  centralized 
team  where  the  main  cost  drivers  are  determi¬ 
ned  and  influenced. 

Only  after  careful  evaluation  and  harmonization 
of  the  requirements  of  the  participating  nations 
each  software  development  team  for  each  com¬ 
puter  .should  be  allowed  to  start  software  design. 
Any  change  of  the  baseline  has  to  be  carefully 
controlled  by  the  centralized  team  and  incorpo¬ 
rated  by  the  software  development  team  after 
authorization  only. 


Methods 


Tools 
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With  regard  to  tools  and  their  underlying 
methodologies  in  international  programs  it  is 
essentia!  to  introduce  the  same  methodology, 
tlie  same  understanding  of  it  and  the  same  tools 
at  all  sites  involved  to  avoid  costly  misunder¬ 
standings  and  duplications.  Defmmg  software 
requirement  specifications  at  different  sites  asks 
for  an  efficient  distributed  data  base.  Due  to 
security  problems  a  direct  link  between  the  host 
computers  at  the  different  sites  has  not  been 
realized. 

Instead  local  data  bases  at  different  sites  arc 
integrated  from  time  to  time  by  a  centra!  team 
to  form  the  central  master  data  base.  The  latter 
is  then  distributed  to  all  parties  involved  and 
forms  the  basis  for  the  next  development  step. 

Current  software  development  methodologies 
and  tools  tend  to  postpone  real  time  aspects  tc 
the  detailed  design  phase.  This  might  be  appro¬ 
priate  for  business  computing,  but  for  avionics 
applications  this  proved  to  cause  problems. 
TTierc  are  cases  where  the  software  design  had 
to  be  radically  changed  because  of  too  extensive 
hierarchical  decomposition  and  the  resulting 
execution  time  overhead.  To  overcome  this  dif¬ 
ficulty  current  practice  calls  for  extrapolating 
this  aspect  from  known  systems  during  the  early 
development  phases.  Prototyping,  to  te  coveted 
in  the  next  section,  can  also  be  very  helpful  in 
this  regard. 


Another  difficulty  when  using  state  of  the  art 
software  development  tools  is  that  they  support 
the  documentation  of  the  lowest  levels  in  great 
detail  but  usually  fail  to  produce  an  easy  under¬ 
standable,  complete  summary  document.  One  of 
tlie  reasons  is  that  the  tools  usually  store 
information  in  an  object  oriented  way,  i.e. 
objects  being  functions  stored  according  to  their 
place  in  the  overall  functional  hierarchy.  Com¬ 
bining  the  description  of  each  of  these  functions 
into  one  document  does  not  necessarily  - 
because  of  the  sheer  size  -  lead  to  a  readable 
document  facilitating  the  dialoge  between 
system  and  software  engineering  and  avoiding 
costly  misunderstandings.  Documents  of  this 
kind  are  also  of  limited  use  for  design  reviews. 


In  order  to  improve  productivity  and  to  reduce 
costs  standards  with  regard  to  high  order  lan¬ 
guages,  processor  architectures  and  develop¬ 
ment  environments  are  already  in  place  or 
emerging.  Within  the  EFA  program,  ADA  and 
STANAG  3910  /  STANAG  3838  are  adopted. 
The  data  bus  standard  STANAG  3910  provides 
for  the  higher  data  rate  requirements  of  the 
avionics  systems  currently  under  development 
(Fig.3).  The  embedded  computing  systems  of 
EFA  are  based  upon  the  68000  processor  family 
indicating  a  trend  to  incorporate  commercial 
parts  or  equipment  into  military  avionics 
systems  and  to  standardize  processor  families 
rather  than  instmction  set  architecmres  (e.g. 
MIL  STD  1750). 
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Fig.  3  Evolution  of  Data  Transfer 
Rates 


This  trend  will  grow  in  the  future  when  speciali¬ 
zed  military  developments  or  standards  are  pro¬ 
hibitive  due  to  the  high  costs  associated  with  the 
low  production  volumes  and  when  commercial 
alternatives  exist.  It  is  also  important  to  note 
whatever  standards  ate  chosen,  they  must  allow 
for  technological  obsolescence  and  changes  of 
the  avionic  system  throughout  the  useful  service 
life  that  is  -  also  out  of  cost  reasons  -  ever 
increasing.  This  especially  holds  true  for  the 
system  architecture  and  the  embedded  proces¬ 
sing  capabilities. 


3.3  Prototyping 


The  experiences  with  the  programs  mentioned 
have  shown,  that  avionics  systems  can  no  lon¬ 
ger  dealt  with  in  terms  of  size,  weight,  cooling 
power  etc.  It  is  also  not  sufficient  to  discuss 
bandwidths,  detection  ranges  and  other  isolated 
performance  criteria.  The  system  defmition  pro¬ 
cess  leading  to  equipment,  software  and  system 
requirements  must  include  an  in  depth  analysis 
of  the  complex  and  interrelated  real  time  effects 
of  integrated  avionics  systems  very  early  in  the 
design  phase  with  as  much  hardware  in  the  loop 
as  possible.  Furthennore  since  user  require¬ 
ments  are  often  not  clearly  stated  cr  misunder¬ 
stood  an  effective  means  has  been  sought  to 
communicate  effectively  between  users,  system 
and  software  engineers  in  order  to  derive  well 
defined  requirements. 

MBB  therefore  installed  a  "System  Prototyping 
Rig"  (SPR)  that  fulfills  the  same  purpose  as 
wind  tunnels  and  test  stands  for  the  airframe 
and  engine  development. 

The  main  of  the  SPR  objectives  are: 

-  Empirical  investigations  of  new  system  archi¬ 
tectures  and  their  complex  real  time  interac¬ 
tion  phenomena 

-  Experimental  feasibility  studies  including 
rapid  prototyping  of  software 

-  Defmition  of  display  fonnats  and  conte.nts 
together  with  air  crews 

-  Investigation  of  new  equipments  in  a  realistic 
avionics  system  environment 

-  Defmition  and  evaluation  of  critical  real  time 
algorithms  e.g.  for  sensor  fusion  and  threat 
management 

-  Inve.sfigation  of  data  transfer  pmr.esses  bet¬ 
ween  various  simulated  or  real  equipments. 


The  SPR  consists  of  a  number  of  graphic  work¬ 
stations,  microcomputcs,  real  aircraft  compu¬ 
ters  and  equipments  as  well  as  displays  and  a 
fully  operable  cockpit.  The  different  pieces  of 


hardware  can  be  connected  in  a  very  flexible 
fashion  via  a  connection  matrix  and  via  diffe¬ 
rent  busses  to  emulate  any  avionics  system  con¬ 
figuration  required.  The  software  installed 
offers  aircraft  models,  several  sensor 
simulations,  powerful  graphics  for  the  cockpit 
displays,  a  software  development  environment 
for  all  computers  and  a  powerful  test  environ¬ 
ment.  Fig.4  gives  an  overview  of  the  SPR  whe¬ 
reas  Fig.5  depicts  a  representative  prototyping 
environment. 


With  regard  to  cost  effectiveness,  the  SPR 
allows  for  critical  early  design  decisions  on  an 
empirical  data  base  where  errors  are  most  costly 
to  correct.  It  is  also  used  for  the  evaluation  of 
software  development  environments  for  target 
computers  and  of  test  support  software.  It  repre¬ 
sents  a  "front  end  investment"  of  effort  to 
reduce  technical  risks,  to  deliver  the  required 
quality  and  to  get  realistic  full  scale  develop¬ 
ment  schedules  and  budgets.  The  early  evalua¬ 
tion  of  system  performance  is  significant  under 
fixed  price  contracts  in  order  to  establish  a  firm 
development  baseline  against  which  the  fulfill¬ 
ment  of  a  development  contract  can  be  measu¬ 
red. 


3.4  Funire  Aspects 


Software  in  sensor  systems  and  mission  compu¬ 
ters  will  continue  to  play  an  ever  increasing  role 
within  avionics  systems.  Reasons  are  the  more 
effective  evaluation  of  sensor  signals  in  order  to 
provide  the  crew  with  higher  level  information 
rather  than  data,  information  fusion  and  the 
reduction  of  reaction  times  of  the  weapon 
system,  A  very  important  prerequisite  is  the 
timely  introduction  of  advanced  embedded 
computers  into  already  existing  military  fighter 
aircraft  during  their  lifetime. 

As  an  example,  MBB  currently  performs  stu¬ 
dies  aiming  at  the  replacement  of  the  main  com¬ 
puter  of  the  weapon  system  Tornado  by  a  form, 
fit  and  function  compatible  central  computer 
which  shall  be  programmed  in  ADA.  The 
existing  main  computer  is  programmed  in 
Assembler  und  represents  with  regard  to  hard¬ 
ware  and  software  the  state  of  the  art  of  the 
70’s.  Due  to  this  fact  we  are  faced  with  a  large 
amount  of  complex  assembler  code  to  be  main¬ 
tained,  high  software  maintenance  costs  and  not 
sufficiently  smictured  software  requirements. 

The  new  computer  with  its  software  rewritten  in 
ADA  shall  provide  sufficient  performance  for  at 
least  20  years,  shall  improve  productivity,  qua¬ 
lity  as  well  as  the  development  time  frames  of 
the  software  and  shall  allow  cost  efficient 


software  upgrades  and  maintenance.  This 
approach  shall  also  provide  the  necessary 
growth  potential  for  new  functions,  e.g.  blen¬ 
ding  of  sensor  data  and  threat  management  in 
cooperation  with  the  defensive  aids  subsystem. 
Finally  the  transition  to  ADA  might  form  the 
basis  for  reusable  software  modules.  This 
approach  will  be  supported  by  the  prototyping 
environment  described  above  and  would  lead  to 
major  development  cost  benefits. 


In  the  longer  mn  there  will  be  more  automated 
tasks  to  free  the  air  crew  for  tactical  planning 
and  supervision  of  the  mission.  TTiis  means  that 
computers  will  also  undertake  safety  and  mis¬ 
sion  critical  functions  in  order  to  increase  the 
survivability  of  the  weapon  system.  Therefore 
rigid  development  methodologies,  dedicated 
testing  and  prototyping  will  further  gain  in 
importance. 


4.  New  Avionic  Architectures 


Reliability,  maintainability  and  testability  are 
the  main  drivers  for  ongoing  efforts  towards 
higher  integration  levels  of  avionics  systems. 
These  efforts,  primarily  aiming  at  the  reduction 
of  acquisition  and  life  cycle  costs,  also  allow  for 
mission  related  advancements  as  increased  fault 
tolerance  and  reconfiguration  in  flight. 

The  design  philosophy  for  these  new  integrated 
architectures  generally  known  under  the  notion 
"Modular  Avionics"  is  that  the  system,  but  not 
neceMarily  a  single  component  has  to  fulfill  the 
mission.  Therefore  modular  avionics  concepts 
are  emerging  where  the  resources  are  shared 
accross  different  functional  components  of  both 
hardware  (Line  Replaceable  Modules)  and  soft¬ 
ware  (software  modules).  This  architecture  sup¬ 
ports  high  degrees  of  system  availability  and 
requires  less  effort  on  system  maintainability 
since  this  approach  makes  a  two  level  mainte¬ 
nance  concept  feasible. 

A  major  contribution  to  the  reduction  of  the 
acquisition  costs  is  achieved  by  the  use  of  a 
limited  number  of  different  types  of  LRM’s 
which  in  turn  leads  to  larger  production  lots.  In 
the  following  emphasis  will  be  given  to  cost 
considerations  and  our  activities  in  this  field. 


4.1  Modular  Avionics 


Starting  at  the  mid  80’s,  several 
European  government  agencies  have  begun 
with  the  sponsoring  of  feasibility  studies  on 
modular  avionics  in  order  to  quantify  the  user 
benefits  emerging  from  this  new  design  philoso¬ 
phy. 

The  results  of  the  German  study  "Neue  Avio- 
nikstrukmr"  have  indicated  that  new  aircraft  as 
well  as  platforms  already  in  service  will  benefit 
from  the  use  of  modular  avionics.  With  regard 
to  upgrade  programs  significant  increases  of  the 
performance  /  volume  ratio  seem  within  reach. 

Although  the  development  costs  of  modular 
systems  might  be  higher  than  their  conventional 
counterparts  savings  during  the  in  service  phase 
will  over-compensate  the  additional  initial 
expenditures. 


In  1987  MBB  started  a  company  funded  R&D 
project  "Modular  Avionics"  in  order  to  carry  out 
more  detailed  investigations  of  these  new  archi- 
tecbires.  Within  this  project  a  Life  Cycle  Cost 
study  has  been  performed  which  is  based  upon  a 
hypothetical  upgrade  of  the  german  Tornado 
fleet  with  new  CNl  systems. 

The  objectives  of  this  study  were  improvements 
of  the  existing  LCC  models  and  more  confi¬ 
dence  for  assessment. 

The  cost  reductions  indicated  in  these  smdies 
are  based  upon  the  reduction  of  parts  in  new 
systems,  simplified  2  level  maintenance  due  to 
failure  detection  to  the  module  level  and  lower 
requirements  for  special  to  type  test  equipment. 

It  should  be  noted  however  that  these  studies  do 
not  take  into  account  additional  measures  to 
adapt  already  existing  avionics  systems  and  air¬ 
craft  strucnires  to  the  new  systems. 


hi  order  to  assess  the  benefits  of  modular  avio¬ 
nics  on  a  experimental  basis  a  prototype  Cock¬ 
pit  Data  Video  and  Voice  Management  System 
(CDVVMS)  has  been  devised  in  cooperation 
with  other  companies. 

This  system  (Fig.6),  aiming  at  the  management 
of  the  audio  and  video  information  in  the  cock¬ 
pit  should  allow  laboratory  demonstrations  in 
1992. 


Sdnsot  Video 
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4.2  European  Initiatives 


The  Allied  Standard  Avionics  Architecture 
Council  (ASAAC)  was  borne  in  1988  as  an 
initiative  of  the  four  Air  Senior  National  Repre¬ 
sentatives  of  the  US,  France,  United  Kingdom 
and  Germany.  'Ihis  government  initiative  is 
mainly  directed  towards  the  harmonization  of 
requirements  and  the  generation  of  standards  for 
the  definition  and  development  of  modular 
avionics. 

National  and  joint  working  goups  have  been  set 
up  in  order  to  develop  the  appropriate  standards 
until  mid  1993. 

Beginning  late  1993  the  validation  of  these 
standards  shall  be  performed  by  means  of  a 
eommon  demonstrator.  This  activity  will  be  car¬ 
ried  out  as  a  joint  program. 


The  lEPG  also  launched  an  initiative  in  order  to 
improve  the  competitiveness  of  the  European 
defense  industry.  The  European  Cooperation  for 
the  Longterm  in  Defense  (EUCLID)  is  aimed  at 
a  broad  range  of  research  in  new  technologies 
and  therefore  divided  in  Common  European 
Priority  Areas  (CEPA's). 

CEPA  4  deals  with  modular  avionics  and  adres- 
ses  by  linked  Research  and  Technology  Projects 
(RTF’s)  the  Europe  wide  development  of 
emerging  technologies  for  modular  avionics. 

ASAAC  and  EUCLID-CEPA  4  ate  complemen¬ 
tary  efforts. 

While  ASAAC  will  generate  and  validate 
standards  with  a  specific  demonstration  subsy¬ 
stem  CEPA  4  wili  develop  and  validate  techno¬ 
logies  for  affordable  integrated  avionics 
systems  in  an  European  environment  and  shall 
form  the  basis  for  the  convergence  of  the  Euro¬ 
pean  R&D  efforts. 
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5.  Possibilicies  for  future  upgrade  programs 


In  the  past  avionics  system  development  and 
acquisition  have  been  driven  -  at  least  in  Europe 
-  by  the  development  of  new  major  weapon 
systems.  With  regard  to  the  new  strategic  situa¬ 
tion  in  Europe,  possible  new  threats,  the  short 
useful  life  of  microelectronic  technology, 
technological  advancements  and  the  increasin¬ 
gly  mission  critical  role  of  avionics  systems, 
new  development  perspectives  targeted  towards 
capability  and  functionality  enhancements  of 
already  existing  platforms  are  on  the  horizon. 
These  perspectives  must  focus  on  the  specific 
needs  of  the  weapon  systems,  on  cost  effective¬ 
ness  and  on  minimum  out-of-service  times, 
since  these  systems  are  already  in  use. 

Reduced  tensions  in  central  Europe  allow  for 
longer  maturity  times  of  new  avionics  systems. 
New  technologies  will  be  in'egrated  if  this  pro¬ 
cess  is  concluded.  New  platforms  wilt  be  rarer, 
due  to  the  high  acquisition  costs  of  new  weapon 
systems  their  useful  in  service  life  wili  be 
expanded  as  much  as  possible.  In  order  to  keep 
these  systems  up  to  date  and  to  adapt  to  new 
technologies,  preplatmed  product  improvement 
programs  for  new  systems  to  be  introduced 
should  already  be  considered  in  the  develop¬ 
ment  phase  i.  e.  system  design  must  allow  for  a 
cost  effective,  long  term  sequence  of  upgrades. 
Design  for  growth,  the  use  of  advanced  simula¬ 
tions  and  extensive  war  gaming  will  increasin¬ 
gly  be  employed  to  determine  the  update  needs 
for  the  years  to  come. 

Within  those  upgrade  programs  cost  effective¬ 
ness  can  be  sought  in  various  ways.  The  most 
obvious  approach  consists  of  the  integration  of 
already  existing  equipment  or  subsystems  deve¬ 
loped  for  other  projects  if  appropriate.  Common 
European  programs  like  Tornado  have  pursued 
up  to  now  common  update  programs  or  modifi¬ 
cations  in  order  to  keep  development  and  acqui¬ 
sition  costs  low  although  the  military  needs  of 
the  three  participating  countries  not  always 
converge.  This  trend  will  probably  continue 
since  the  upcoming  treaties  will  limit  the  num¬ 
ber  of  combat  aircraft  available  and  cost  effecti¬ 
veness  also  means  large  production  mns  of 
avionics  equipment  or  modules. 

Since  "change"  is  obviously  a  requirement 
throughout  die  life  of  a  system  a  certain  level  of 
research  and  developoment  funding  is  necessaiy 
during  the  complete  life  cycle  of  a  weapon 
system.  In  the  following  potential  areas  for 
upgrades  and  improvements  in  the  1990’s  will 
be  discussed. 

MBB  is  currently  conductmg  studies  with 
regard  to  further  improvements  of  survivability, 
force  multiplication  and  flexibility  of  the  Tor¬ 
nado  weapon  system.  These  studies  are  centered 
around  crew  workload  reduction,  covert 


operation  and  further  enhancements  of  the  night 
fighting  /  bad  weather  and  electronic  warfare 
capabilities.  We  also  consider  new  emerging 
NATO  wide  requirements  as  the  introduction  of 
GPS,  MLS  and  NIS  as  well  as  provisions  for 
fiiture  -  e.g.  stand-off- weapons. 

Crew  workload  reduction  is  aiming  at  the  full 
exploitation  of  the  built-in  flexibility  and  multi¬ 
mission  capability  of  this  combat  aircraft.  This 
seems  only  possible  with  higher  degrees  of 
automation  to  free  the  air  crew  from  time  con¬ 
suming  ta.sks  and  to  enable  faster  reaction  times 
of  the  system.  In  order  to  address  properly  the 
workload  associated  with  the  various  tasks  of 
the  crew  we  employed  an  expert  system  called 
ESAT  ("Expertensystem  filr  Aufgabentaxono- 
mie")  developed  at  MBB.  The  results  of  these 
investigations  were  fed  into  the  cockpit  redesign 
process.  We  also  use  the  prototyping  of  displays 
described  above  to  evaluate  human  response. 
One  outcome  of  these  investigations  is  the  deci¬ 
sion  to  propose  the  additional  introduction  of 
tactical  colour  displays  in  the  front  as  well  as  in 
the  rear  cockpit  and  to  employ  a  colour  terrain 
following  display.  If  possible  these  changes 
together  with  the  necessary  updates  of  the  com¬ 
puter  symbol  generator  will  contain  concepts 
based  upon  the  Modular  Avionics  approach. 

The  main  constraints  to  be  resolveu  with  regard 
to  full  application  of  Modular  Avionics  within 
upgrade  programs  are: 

-  the  additional  effort  for  the  integration  of 
modular  subsystems  into  the  already  existing 
conventional  environment  with  its  many  spe¬ 
cial  interfaces,  adaptors  and  connectors 

-  the  existing  test  and  maintenance  concept 

-  the  mechanical  boundary  conditions  of  the 
aircraft  (this  refers  to  the  inuoduction  of  a 
standard  integration  tack) 

Crew  workload  reduction  also  means  the  imple¬ 
mentation  of  automatet  real  time  decision  sup¬ 
port  systems  and  their  data  base  management 
systems  on  board  of  the  aircraft.  The  first  step 
towards  this  goal  consists  of  a  prototype  TTueat 
Management  System  (TMS)  realized  at  MBB  in 
cooperation  with  Texas  Instruments  in  order  to 
facilitate  the  dialogue  with  the  user,  to  derive 
early  performance  data  and  to  verify  die  design 
and  development  environment  (Fig.7).  The 
main  task  of  the  TMS  is  the  blending  of  the  data 
of  various  sensors  and  the  enhancement  of  these 
data  with  the  contents  of  stored  knowledge 
bases  in  order  to  analyse  the  threat  and  to  derive 
tactical  decision  support  information  for  the 
crew  in  dense  air  defense  environments. 


The  notion  "Covert  Operation"  refers  to  the 
introduction  of  a  Terrain  Referenced  Navigation 
(TRN)  system.  MEB  presently  conducts  flight 
tests  of  a  german  prototype  TRN  called 
LATAN  in  order  to  derive  flight  test  and  perfor¬ 
mance  data  of  such  a  system.  The  TRN  shall 
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allow  low  level  penetration  missions  where  the 
self-generated  vulnerability  due  to  the  radiation 
of  the  terrain  following  radar  must  be  avoided. 
The  digital  terrain  and  elevation  database  of  the 
TRN  can  be  augmented  by  threat  data  derived 
either  from  intelligence  sources  or  from  an  on 
board  emitter  locator  system  to  support  the 
TMS  already  described. 

Increased  sihiation  awareness  is  also  an  area 
under  consideration.  Tne  advancements  in  the 
electro-optics  field  led  to  investigations  of  the 
integration  of  a  fixed  or  moveable  FLIR  sensor 
combined  with  a  Helmet  Mounted  Display. 
Together  with  corresponding  enhancements  of 
the  mission  software  the  FLIR  sensor  data  may 
also  be  used  for  fire  control  during  night. 

Reconnaissance  plays  an  increasing  role  in  the 
central  Europe  of  today  where  fewer  forces 
have  to  cover  larger  areas.  The  RF-4E’.s  of  the 
German  Air  Force  will  be  taken  out  of  service 
within  the  next  few  years.  This  will  leave  the 
GAF  with  reduced  tactical  reconnaissance  capa¬ 
bilities  if  no  other  measures  are  taken.  There¬ 
fore  a  concept  phase  is  under  way  aiming  at  the 
introduction  of  reconnaissance  p^s  for  a 
certain  number  of  Tornado  aircraft.  Out  of  cost 
reasons  these  pods  .shall  be  based  iiiion  the 
already  existing  recce  pods  of  the  Tornados 
flown  by  the  German  Navy. 


Further  cost  saving  measures  could  be  the  use 
of  infrared  line  scanners  developed  for  other 
programs,  the  Infrared  Imaging  System  of  the 
ECR  Tornado  beeing  an  example. 

Advancements  in  technology  point  towards 
digital  image  processing,  storage  and  retrieval 
methods  for  the  infrared  images  already  sent  as 
digital  data  from  the  sensor.  Digital  image  pro¬ 
cessing  allows  for  near  real  time  on  board  eva¬ 
luation  and  manipulation  of  the  sensor  data.  The 
images  or  subsets  of  them  can  be  transmitted 
via  digital  data  links  to  follow  on  forces  or 
ground  stations  speeding  up  even  further  the 
near  real  time  dissemination  of  reconnaissance 
data.  Presently  the  definition  of  appropriate 
system  architectures  and  subsystems  is  under 
way  at  MBB. 


6.  Summary 


Limited  budgets,  fewer  forces  and  changing 
threats  ate  the  main  constraints  to  be  expected 
during  the  years  to  come.  Since  flexibility,  sur¬ 
vivability,  availability  and  cost  of  ownership  of 
modem  aeronautical  weapons  systems 


increasingly  rely  upon  its  avionics  systems  and 
the  capabilities  offered  by  advanced  sensors, 
processors  and  system  software,  cost  effective 
approaches  for  the  development  and  acquisition 
of  avionics  systems  are  sought. 


The  examples  given  in  this  lecture  point 
towards  increased  maturity  times  of  new  tech¬ 
nologies,  stronger  prototyping  efforts  in  the 
early  desigrt  phases  and  die  application  of  rigid 
development  methodologies  including  the  tran¬ 
sition  to  ADA  in  the  software  field  in  order  to 
keep  weapons  systems  and  their  inevitable 
upgrades  affordable.  Important  prerequisites  in 
this  regard  are  stable  research  and  development 
funds,  the  exploitation  of  commercial  technolo¬ 
gies  and  the  use  of  already  existing  equipment 
wherever  possible. 


New  avionic  architectures  aiming  at  higher  inte¬ 
gration  levels  will  bring  further  advances  with 
regard  to  maintainability,  reliability  and  life 
cycle  costs.  In  order  to  maximize  the  benefits 
resulting  from  these  approaches,  joint  European 
initiatives  are  under  way  to  harmonize  the 
requirements  of  the  participating  nations  and  to 
validate  the  necessary  standards.  Prototyping 
and  modular  avionics  will  support  those  areas, 
where  upgrade  needs  in  the  next  years  are  most 
obvious,  i.e.  the  cockpit  area  and  the  sharing 
and  the  expansion  of  computer  resources. 
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AVIONICS  MODERNIZATIONS/UPGRADES  IN  THE  LATE  1990s 
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1  ■  SUMMARY 


Change  is  the  most  prevalent  event  we 
can  expect  during  the  life  of  a  weapon 
system.  In  an  avionics  system,  change 
is  brought  about  for  two  primary 
reasons:  correcting  problems  or  adding 
capability.-  In  many  cases  it  costs  less 
to  upgrade  older  aircraft  than  develop  a 
new  one.  How  we  plan  for  those  upgrades 
makes  the  difference. 

2 .  BACKGROUND 

Current  US  military  aircraft  have  a 
mixed  bag  of  avionics  architectures  due 
to  the  technology  available  when  they 
were  designed.-  Aircraft  from  the  6O3 
and  early  TOs  were  built  using  single 
function  avionics  subsystems 
interconnected  by  point  to  point  wiring. 
Pilots  interpreted  displayed 
information,  made  assessments  and 
reacted  to  the  stimuli. 

Architectures  began  using  multiplex  data 
busses  in  the  70s.  Multiplex  busses 
made  it  easier  to  interconnect  avionics 
equipment  or  black  boxes  and  at  the  szutie 
time,  reduced  weight  of  avionics  wiring. 
This  resulted  in  even  more  information 
for  the  pilot  to  interpret .  Distributed 
architectures  and  integrated  avionics 
were  developed  in  the  80s.  In  essence, 
designers  attempted  to  relieve  the  pilot 
and  central  processor  from  some  of  the 
workload  and  get  raw  information  to  the 
subsystems  needing  it  without  pilot 
interpretation  or  intervention. 

3.  AVIONIC.3  UPGRADE.*; 

Avionics  upgrades  are  made  for  two  major 
reasons:  Performance  or  Supportability . 
Equipment  is  not  replaced  just  because 
it  is  performs  better  or  is  more 
reliable.  Modifications  which  improve 
performance  usually  are  a  response  to  a 
new  or  perceived  new  threat.  Detsction 
ranges,  number  of  and  type  of  threats, 
frequency  ranges,  and  target 
observability  are  examples  of 
capabilities  that  change  dramatically 
over  the  life  of  a  weapon  system. 

3.1  Capability  Improvements 

In  the  past,  a  new  capability  often 
required  new  displays .  Multifunction 
displays  replaced  separate  instruments 
because  we  ran  out  of  cockpit  space. 
Pilot  workload  became  a  limiting  factor 
in  operating  weapons  systems  originally 
designed  with  single  function  avionics. 
More  computational  power  was  added  to 
help  the  pilot  with  situation  awareness. 
And  still  more  computational  power  is 
needed  now  to  automate  functions. 


Few  weapons  systems  were  originally 
design  for  today' 3  environment  in  mind 
either  due  to  technology  risk,  cost,  or 
unknown  threats.  Government  person:  : 
try  to  predict  growth  requirements,  but 
within  5  to  10  years,  growth  capability 
is  consumed  by  enhancements  needed  to 
meet  a  new  threat .  A  good  example  of 
this,  is  the  memory  growth  experience  of 
one  of  our  fighter  aircraft.  In  1975, 
it  had  32K  of  memory.  In  1979  it  was 
upgraded  to  64K,  in  1984  to  128K,  and 
now  has  512K. 

3.2  Supportability  Improvements 

Supportability  includes  the  equipment 
and  manpower  required  to  •maintain  the 
weapons  system.  Modifications  which 
improve  supportability  are  usually  a 
response  to  budget  constraints.  Low 
reliability  leads  to  high  repair  and 
maintenance  costs.  Obsolescence  is  a 
major  problem  because  repairing  old 
technology  becomes  costly  when  parts  are 
no  longer  available.  We  resort  to 
restarting  component  production  lines, 
redesigning  equipment  to  use  currently 
available  components,  or  developing  new 
equipment  to  keep  old  weapons  systems 
operational . 

3.2.1  Maintenance  Philosophy 

Currently,  aircraft  are  maintained 
using  a  three  level  maintenance  concept 

-  flight  line  (at  aircraft  with  little 
test  equipment  and  few  tools) , 
intermediate  (local  base  facility) ,  and 
depot  (regional  repair  facility) . 
Different  types  of  test  equipment  are 
used  at  each  level.  Reducing  the  number 
of  maintenance  levels,  amount  of  test 
equlpme;  t  and  spare  parts  will  reduce 
support  costs.  This  can  only  be  done 
when  equipment  reliability  is  reasonably 
high.  With  this  high  reliability, 
reduction  to  two  levels  of  maintenance  - 
flight  line  and  depot,  or  just  one  level 

-  flight  line,  would  reduce  number  of 
people  required  to  maintain  avionics 
systems.  In  the  first  instance, 
avionics  must  be  designed  to  be  repaired 
at  the  flight  line,  typically  a  remove 
and  replace  phil.osophy .  In  the  second 
instance,  a  depot  would  not  be  needed, 
essentially  a  throw-away  philosophy. 

In  the  70s  we  started  using  multiplex 
busses  which  reduce  wiring  weight.  Cost 
reduction  was  the  reason  -  lower  weight 
reduces  fuel  consumption,  allowed  more 
fuel  for  longer  missions.  Additionally, 
avionics  system  reliability  imjgroved  by 
reducing  the  number  of  connections  and 
providing  redundant  data  paths . 


9-2 


However,  there  was  no  reduction  in  test 
equipment  or  manpower. 

3.2.2  Availability  Improvements 

Availabiliti  is  also  a  factor.  The 
newer  something  is,  the  less  likely  it 
is  to  fail.  If  aircraft  don't  break  as 
often,  they  will  be  ready  when  needed, 
fewer  spares  will  be  required  and  fewer 
maintainers  need  be  trained  and 
supported . 

3.3  Technology's  Contribution 

In  many  cases,  original  avionics  have 
been  replaced  with  more  capable,  more 
reliable,  lighter,  and  less  expensive 
avionics  subsystems.  Technology  break¬ 
through  has  provided  these  improvements. 
New  technology  has  fewer  components  and 
requires  less  manual  labor  to  build.  It 
has  proven  to  be  more  reliable,  thus 
requires  less  maintenance.  Much  has 
happened  over  the  last  20  years. 
Reliability  is  still  improving  and  coats 
are  coming  down.  Thanks  to  use  of  newer 
technology,  computer  aided  design  and 
computer  aided  manufacturing. 

3.3.1  Diagnostics  Improvements 

1970s  generation  of  avionics  utilized 
built-In-test  (BIT)  features  designed  to 
identify  avionics  failures  within  a  line 
replaceable  unit  (LRU)  and  typically 
signaled  only  which  LRU  had  failed.  The 
additional  circuitry  required  foi  BIT 
increased  complexity  and  reduced 
reliabilty.  Many  BIT  systems  functioned 
so  poorly  that  only  a  group  of  LRUs 
could  be  identified,  requiring  that  all 
related  LRUs  be  removed  and  tested 
individually  at  the  local  base  facility. 
Aircraft  electrical  interfaces  were  not 
typically  part  of  the  avionics  LRU 
built-in-test  equipment  and  had  to  be 
tested  separately. 

New  integrated  circuits  are  designed 
with  built-in  diagnostics,  i.e.,  the 
ability  to  test  themselves.  Large 
complex  bulky  unreliable  and  expensive 
automatic  test  equipment  can  be  replaced 
with  suitcase  testers  or  completely 
eliminated  depending  on  the  level  of 
diagnostics  designed  into  components  and 
systems.  This  single  technological 
breakthrough  is  the  reason  two  level 
maintenance  phi losophies  are  now 
possible.  Elimination  of  need  for  the 
avionics  intermediate  level  repair  shop 
(AIS)  is  a  goal  of  new  aircraft  avionics 
systems  programs . 

3.3.2  Software  Improvements 


software  engineering  environments  will 
be  used  to  correct  software 
deficiencies,  develop  operational 
enhancements,  and  test  interfaces.  Yet, 
complex  systems  will  still  require 
thorough  and  time  consuming  validation 
to  ensure  proper  operation  in  all  flight 
conditions . 

3.3.3  Paekaoing  Improvements 

Older  avionics  subsystems  are  packaged 
as  Line  Replaceable  Units  (LRUs) .  Most 
are  convection  or  forced-air  cooled. 
Newer  tochnology  avionics  will  be 
pao)caged  as  Line  Replaceable  Modules 
(LRMs)  and  may  be  convection,  forced-air 
or  liquid  cooled.  As  a  comparison,  a 
single  (6  inch  x  5.8  inch  x  0.6  inch) 

LRM  may  have  capability  equivalent  to  or 
greater  than  an  (8  inch  x  20  inch  x  8 
inch)  LRU. 

LRMs  will  be  needed  to  implement  the 
two-level  or  one-level  maintenance 
philosophy.  LRUs  protected  electronic 
components  from  severe  flight  line 
environments  in  the  past.  LRMs  must 
provide  the  same  and  likely  more 
protection.  These  almost  pocketsized 
electronic  gadgets  are  likely  to  be 
roughly  handled,  dropped,  dunked,  and 
exposed  to  electostatlc  discharge, 
whereas  LRUs  were  usually  treated  as 
sensitive  electronics  boxes., 

3.4  Minor  Change  vs  Major  Change 

How  much  of  a  change  is  economical?  An 
item  manager  must  satisfy  his  user 
within  a  restricted  budget  and  typically 
on  a  problem  by  problem  basis.  Usually 
only  high  priority  or  safety-of-flight 
changes  are  made. 

The  addition  of  a  new  "dumb"  bomb  might 
have  no  impact  on  aircraft  hardware  or 
release  mechanisms.  As  a  minimum,  new 
aerodynamic  parameters  or  release 
computations  in  operational  flight 
software  might  be  required  in  the  stores 
management  system. 

Sometimes  modifications  impact 
peripheral  equipment .  Addition  of  a 
guided  weapon,  smart  weapon  or  new 
sensor  might  impact  the  connector, 
require  additional  wiring  and/or  fiber 
optic  cable,  require  new  control 
algorithms  in  operational  software,  and 
require  modification  of  other  avionics, 
for  example,  to  provide  navigation  and 
air  data  to  the  weapon.  It  rs  even 
possible  that  newer  weapons  could  even 
impact  flight  control  software.  Impacts 
on  aircraft  power  and  cooling 
capabilities  must  closely  be  controlled. 


In  the  past,  avionics  improvements  were 
accomplished  u.jing  hardware  redesign,  an 
expensive  lengthy  process  which  seldom 
kept  pace  with  changing  threats. 
Equipment  complexity  further  added  to 
the  redesign  problem.  Modern  software 
driven  digital  technology  promises 
quicker  upgrades  through  software 
changes.  Hardware  changes,  in  most 
cases,  are  not  required.  Modern 


3.4.1  Technology  Mix 

Old  generation  avionics  are  removed  from 
an  aircraft  and  replaced  with  new 
components  having  10  times  the 
reliability,  and  weighing  less  than  half 
the  original  avionics. 

How  two  radically  different 
technologies  can  be  mixed  is  one  of  the  I 
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big  questions. 

Hewer  generation  avionics  operate  at 
lower  supply  voltages  and  are  more 
sensitive  to  electromagnetic 
interference.  Digital  signals  within 
new  electronics  could  cause  interference 
with  older  generation  receivers.  Better 
power  filtration  may  be  required  when 
new  equipment  is  used  on  older  aircraft. 

Older  aircraft  often  have  inadequate 
cooling  for  avionics  systems.  Although 
a  problem  to  overcome,  new  equipment 
operates  at  lower  power  levels  and  may 
reduce  cooling  load  on  other  avionics 
subsystems . 

Where  does  modular  avionics  fit  into 
modifications  of  older  aircraft? 

Most  avionics  is  designed  to  fit  into 
available  space.  If  modular  avionics 
packaging  technology  were  to  be  used, 
remaining  older  generation  avionics  may 
have  to  be  moved  to  permit  installation 
of  a  rack  for  the  modules.  Long  term 
planning  must  be  done  to  allow  space  for 
other  upgrade  without  impacting 
completed  modifioaitons . 

How  does  modular  avionics  systems 
architecture  (MASA)  fit  into  a  force 
structure  that  might  be  made  of  up  all 
type  of  aircraft,  i.e.,  fighters, 
bombers,  tankers,  cargo  aircraft,  rescue 
aircraft  and  command  and  control 
aircraft  all  belonging  to  the  same 
deployable  unit? 

A  force  structure  made  up  of  many  types 
of  aircraft  today  would  require  a  set  of 
support  equipment  for  each  aircraft  type 
due  to  the  use  of  different  avionics 
(and  other  equipment)  in  each  aircraft. 
Deploying  such  a  force  would  be  a  large 
effort.  If  common  or  standard  equipment 
were  used  across  many  aircraft,  only  one 
set  of  test  equipment  (i.e.  the  common 
denominators)  would  be  required. 

Is  there  not  some  point  where  it  makes 
sense  that  portions  of  the  avionics 
subsystems  become  interchangeable? 

Form  fit,  function,  and  interface  F^l 
standards  were  seen  as  the  appropriate 
level  of  standardization  in  the  70s  and 
80s.  In  a  sense,  ^SA  could  also  be 
thought  of  as  an  F^I  approach  to 
standardization.  The  MASA  and  JIAWG 
concepts  require  that  like  modules 
(built  to  the  Scune  functional 
specification  by  different  vendors)  be 
validated  or  certified  as  being 
interchangeable.  Whether  f3i  can  be 
accomplished  or  not  must  still  be 
demonstrated  -  the  back  up  approach  is 
build-to-print  standardization. 

Upgrades  of  a  particular  avionics 
subsystem  or  function  across  many 
aircraft  are  potential  candidates  for 
common  equipment  or  components  which  are 
interchangeable ., 

Upgrades  of  related  avionics  functions 
on  a  single  aircraft,  such  as 


communication  or  processing,  are 

candidates  for  common  equipment  or 
interchangeable  components  when  3  or 
more  subsystems  are  replaced  by  a 
modular  system.  Studies  have  shown  that 
savings  begin  to  accrue  when  the  modular 
components  overhead  becomes 
insignificant  (typically  3  or  more 
subsystems) .  A  characteristic  of 
modular  avionics  is  the  ability  to 
utilize  common  or  interchangeable 
modules . 

Consideration  must  be  given  to  related 
changes  in  space,  cooling  and  other 
interface  modifications  needed  to  allow 
installation  of  a  modular  system. 
Upgrades  using  modular  avionics  do  not 
reduce  support  c  quipment  requirements 
for  remaining  unchanged  avionics,  thus 
changing  all  communication  or  processing 
provides  a  cultural  change  to  the 
support  environment . 


Years  ago,  the  USAF  attempted  to  create 
form  fit  functional  standards  to  allow 
items  like  an  inertial  navigation  system 
to  be  used  across  many  aircraft. 
Differences  in  avionics  suites, 
interfaces  and  performance  requirements 
limited  the  success  of  that  endeavor. 
Current  efforts  within  the  Joint 
Integrated  Avionics  Working  Group 
(JIAWG)  may  evolve  an  avionics  suite 
that  can  be  applied  to  multiple 
aircraft.  In  a  sense,  this  work  is 
providing  a  means  to  upgrade  older 
aircraft  using  current  technology.  From 
the  Advanced  Tactical  Fighter  (ATF)  and 
JIAWG,  there  will  be  a  baseline  set  of 
common  avionics  modules,  which  can  be 
used  as  building  blocks  to  upgrade  or 
replace  subsystems  in  older  aircraft . 
When  not  adequate,  other  models  will  be 
developed.  Modules  designed  for 
multiple  applications  (i.e.  standard 
modules)  will  eventually  be  added  to  the 
"module  super  market". 


Originally,  aircraft  are  design  for  a  20 
year  life  cycle,  but  many  are  already 
beyond  that.  The  B-52  was  designed  in 
the  early  50s.  The  F-llls  were  designed 
in  the  late  60s.  KC-1353  are  a 

derivative  of  the  Boeing  707  which  was 
designed  in  the  late  50s.  It  is 
possible  the  KC-135  aircraft  will  be 
extended  to  2045.  Due  to  high  cost  of 
new  aircraft,  there  is  strong  motivation 
to  upgrade  older  aircraft.  Currently 
major  retrofits  are  being  planned  for 
KC-135,  C-130,  F-16  and  F-15  aircraft. 

The  following  is  a  list  of  research  and 
development  projects  and  related 
modification  projects  already  planned. 
The  list  changes  daily,  based  on 
budgetary  and  other  organizational 
priorities. 


9-4 


1 


AF  Projeotai 


Offensive  Avionics 

R«D 

22 

Mods 

26 

Defensive  Avionics 

26 

48 

Communication  Systems 

13 

51 

Navigation  Systems 

6 

60 

Identification  Systems 

5 

1 

Controls  and  Displays 

4 

16 

Flight  Control  Systems 

9 

8 

Status  Monitoring 

1 

21 

Computers  and  Software 

7 

7 

Tech  -  Multiple  Appl. 

15 

0 

Avionics  Modernization 

3 

10 

RSM 

5 

0 

Trainers  and  Simulators 

9 

11 

Integrated  Avionics 

_ 2 

_ 2 

Total  Projects 

125 

259 

These  projects  cover  various  technology 
areas  and  equipment  including:  paper 
tape  reader  replacement,  warning 
receiver  improvement,  new  Identification 
Friend  or  Foe  (IFF)  systems, 
countermeasures,  self  protection 
systems.  Reliability  and  Maintainability 
(RSM)  improvements,  Electro-Optical  (EO) 
systems.  Laser,  Directed  energy  weapons, 
side  looking  airborne  radar  sensors, 
other  radar  component  improvements, 
modem  capability,  data  transmission  and 
reception,  automatic  target  handoff, 
anti-jam  &  secure  communication,  covert 
airborne  communication,  nuclear 
detection  capability,  global  positioning 
system  (GPS) ,  microwave  landing  system 
(MLS) ,  satellite  communication,  helmet 
mounted  systems,  fuel  savings  systems, 
airborne  data  recorders,  flight  data 
recorders,  crash  recorders,  autopilots, 
and  target  recognition.  None  of  these 
projects  currently  employ  use  of  modular 
avionics . 

3.6  Predictions 

Looking  at  our  current  inventory,  it  is 
relatively  easy  to  predict  that 
modifications  will  be  made  to  replace 
unsupportable  equipment .  Reliability  is 
easy  to  measure.  Repair  and  replacement 
cost  can  also  be  monitored.  Technology 
revolution  leaves  older  technology 
unsupportable  as  quickly  as  5  years 
after  introduction.  Avionics  systems 
that  are  10  or  more  years  old  are 
becoming  difficult  to  support. 

It  is  more  difficult  to  predict  new 
threats  and  required  capabilities. 

Damage  tolerant  flight  control  and 
engine  control  systems  are  likely. 

Flight  controls  may  need  to  be  coupled 
to  navigation  information  and 
communication  equipment  to  meet  FAA 
requirements  for  collision  avoidance. 
Previous  studies  have  identified  new 
requirements  for  Gunship,  a  follow  on 
replacement  for  Wild  Weasel  based  on 
modifications  to  F-15s  or  F-16s; 
enUjedded  training  requirements;  special 
forces  airciaft  requirements;  a  close 
air  support  aircraft  replacement  for  the 
A-10;  next  generation  tactical  airlift 
capability;  aerial  refueling  concepts, 
new  tactical  air-to-surface  weapons 


systems;  farterm  F-15,  F-16,  F-111,  and 

A-10  modernizations,  and  integrated 
flight  -  crew  systems  -  and  cockpit 
systems . 

In  either  case,  architectural  features 
are  available  to  allow  replacement/ 
upgrade  in  an  orderly  rather  than 
haphazard  fashion.  The  1553  multiplex 
bus  allowed  this  in  the  past.  In  the 
future,  backplane  standards  will  control 
physical  and  electrical  interfaces  and 
allow  replacement  of  unsupportable  or 
obsolete  modules  or  addition  of  new 
capabilities  with  little  or  no  impact  to 
the  aircraft. 

3.6.1  Planning  for  Periodic  Upgrades 

Those  organizations  responsible  for 
identifying  development  requirements 
must  consolidate  need  statements  from 
all  users  and  identify  similarities.  By 
grouping  functional  requirements, 
communication  enhancements  of  all  users 
for  instance,  a  common  item  might  serve 
all  and  save  development  funds  as  well 
as  serve  to  eliminate  incompatibilities 
among  weapons  platforms.  Reductions  in 
support  equipment  development  and 
training  follow  naturally. 

The  Avionics  Planning  Baseline  Document 
contains  a  list  of  ongoing  and  planned 
modification  over  a  10  year  period  for 
all  mission  design  series  aircraft.  A 
sort  of  this  data  shows  modifications  to 
incorporate  the  following  types  of  RF 
systems  on  most  US  aircraft:  GPS,  Have 
Quick,  and  MLS.  Another  sort  shows 
upgrades  being  made  to  many  radar 
systems . 

Under  the  right  political  and  economic 
conditions,  a  modular  avionics  systems 
architecture  could  be  installed  to 
accomodate  these  and  many  future  changes 
in  a  synchronized,  coordinated  manner. 

3.6.2  Example  Upgrade  -  Tanker  Trans¬ 
port  Common  Radar 

Current  weather  radars  used  in  C-130  and 
others  in  other  aircraft  are  becoming 
difficult  to  .support.  Many  were 
developed  along  with  the  aircraft,  eons 
ago.  Some  have  been  improved,  but 
remain  dependent  on  an  aging  technology 
base . 

Currently,  1900  transport/cargo 
aircraft2  have  a  radar  with  reliability 
less  than  300  hrs.  A  life  cycle  cost 
comparison  of  a  new  radar  versus 
continuing  support  for  older  radar 
systems  indicates  a  break  even  in  9 
years.  The  following  assumptions  were 
used: 


Development  Costs  -  $15m 
Unit  Cost  -  $150K 
1900  Units 

Two  Level  Maintenance  Concept 
One  Depot 

72  Hours/Month  Operation 
One  year  standard  Warranty 
MTBF  of  750  hrs 


A  new  radar  would  have  digital 
technology,  modular  architecture,  and 
standard  1553  ana  video  interfaces. 

Such  .a  radar  could  meet  all  users 
current  requirements .  Rather  than  spend 
development  dollars  to  upgrade  each  type 
of  radar  in  each  aircraft,  one  common 
new  radar  could  be  developed  at  a 
savings  and  be  applied  to  all 
transports.  In  the  long  run,  the  Air 
Force  will  save  money  by  eliminating  a 
radar  with  poor  reliability,  save  money 
by  consolidating  a  number  of  upgrades 
into  one  development  effort,  and  by 
applying  this  new  radar  to  many 
aircraft..  Upgrades  in  the  90a  will  be 
extremely  sensitive  to  cost  factors. 

4.  References 

1.  ASD-TR-90-5011,  Avionics  Planning 
Baseline 

2.  Air  Force  Avionics  Roadmap 
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Abstract: 

The  development  of  avionics  through  the  application  of 
traditional  hlIL-STD-785,  Reliability  Pmgr^  for  Systems 
and  Equipment  Development  and  Producuon.  development 
processes  for  Avionic  Reliability,  has  proven  to  have  several 
advantages,  disadvantages,  and  limitations.  This  process  will 
be  contrasted  with  the  Avionics  Integrity  process  which  is 
based  upon  a  knowledge  of  how  the  equipment  is  to  be  used, 
the  actual  environments  of  the  operating  equipment  and  the 
application  of  fatigue  theory  and  life  laws  to  design.  The 
process  Is  based  upon  a  detailed  understanding  of  the 
characteristics  of  the  parts,  materials  and  associated  processes 
used  in  its  manufacturer,  and  the  tailoring  of  the  process 
controls,  inspection  and  test  requirements.  The  outcome  of  the 
process  will  be  avionics  with  a  minimum  life  that  is  dependent 
upon  the  operational  stresses  applied.  Addidonally,  a  number 
of  conflicts  associated  with  the  use  of  standard  envuonments, 
standard  parts,  the  use  of  redundancy,  who  is  responsible  for 
reliability,  MIL-SPEC  design  criteria.  Mean  Time  Between 
Failure  as  a  metric,  and  warranties  are  also  addressed. 

Introduction: 

Avionics  standardization  has  been  developing  over  a  period  of 
years  to  provide  a  functional  capability  for  the  United  States 
and  our  allies  armed  forces.  Tiuough  the  development  of 
standard  avionic  equipments,  we  have  taken  advantage  of  the 
economics  of  manufacturing  large  numbers  of  equipment  to  a 
single  design  rather  than  a  few  equipments  fiom  each  of 
several  designs  to  perform  a  specified  function.  The  net  result 
being  a  considerable  cost  savings.  These  economies  also 
apply  to  the  support  of  the  standard  equipments  through 
provisions  for  spare  units,  piece  parts  and  tiie  support 
equipment  for  one  design  rather  than  multiple  designs. 
Although  there  have  been  some  development  problems  with 
standard  equipment,  the  large  production  quantities  and 
warranties  have  usually  provided  sufficient  economic 
incentive  for  the  contractors  to  correct  design  and 
manufacturing  process  shortcomings,  and  has  generally 
resulted  in  acceptable  field  reliability. 

Requirements  for  many  of  the  standard  equipments  in  the 
United  States  inventory  have  been  developed  in  conjunction 
with  our  allies,  sometimes  to  international  specifications. 

Thus  standardization  has  become  an  integral  part  of  the  way 
we  do  business. 

Standard  equipments  are  typically  specified  based  upon  their 
functional  performance  and  reliability  at  the  line  replaceable 
unit  or  subsystem  level.  And  the  performance  is  based  on 
laboratory  condidons  rather  than  the  installed  performance. 
This  has  worked  out  reasonably  well  for  standard  equipments; 
i.e.  inertial  navigation  systems.  Identification  Friend  or  Foe 


(IFF)  systems,  the  Standard  Cenual  Air  Data  Computer  and 
HF,  VHF  and  UHF  radios. 

An  example  of  acceptable  functional  performance  would  be  an 
inertial  navigation  system  which  is  essentially  the  same 
whether  it  is  installed  on  a  fighter,  cargo  or  commercial 
aircraft.  IFF  systems  and  UHF/VHF  radios,  on  the  other  hand, 
are  dependent  on  the  performance  of  the  Receiver/Transmitter, 
the  antenna  patterns  and  insertion  loss  of  the  antenna  cable. 
The  HF  radio  performance  is  dependent  on  the  aircraft's 
antenna  coupler/antenna  design.  The  limitations  of  the  HF 
installation  is  often  accommodated  by  the  judicious  selection 
of  frequencies  during  day  to  day  operations  Unfortunately, 
the  reliability  or  durability  of  each  of  these  systems  may  be 
quite  different  depending  upon  how  the  equipments  are  used 
and  the  working  environments.  The  installation  agency  has 
typically  been  thought  to  be  responsible  for  making  the 
equipments  work  in  the  aircraft,  but  this  has  resulted  in 
numerous  disputes  over  who  might  be  ultimately  held 
responsible. 

The  reliability  requirement  is  stated  as  a  minimum  Mean  Time 
Between  Failure  (MTBF)  and  may  be  verified  under 
laboratory  conditions  to  a  specified  confidence  level.  The 
problem  anses  with  the  correlation  between  MTBFs 
demonsuated  in  the  laboratory  and  those  experienced  in  the 
field.  The  user  and  maintainer  have  multiplied  the  laboratory 
demonsuated  MTBF  by  a  factor  to  adjust  reliability 
expectations  for  the  particular  field  conditions.  This  type  of 
adjustment  factor  takes  into  account  the  logisticians 
experience  with  similar  equipments,  the  equipments 
manufacturer,  the  individuals  tolerance  for  nsk  and  the 
budgetary  constraints.  All  these  factors  are  used  for 
maintenance  planning,  determining  how  many  spare  units  and 
piece  parts  arc  to  be  purchased,  and  the  manpower  levels 
necessary  to  support  the  equipment.  Often  the  reliability  of 
similar  equipment  varies  widely  when  installed  on  different 
platforms  (see  Figure  1).  The  outcome  of  this  process  is 
frustration  for  the  users  and  maintainers.  They  have  become 
accustomed  to  these  uncertainties  and  up  to  now  have  been 
forced  to  accept  them. 

Historical  Perspective: 

There  has  been  an  interesting  evolution  in  the  way  the  military 
and  industry  addressed  reliability.  It  has  involved  a  series  of 
decisions,  each  of  which  were  made  for  good  reason  with  the 
data  available  at  the  time.  Unfortunately,  these  decisions 
resulted  in  the  formation  of  a  series  of  disciplines  or  "ilities” 
(reliability,  maintainability,  producibility,  etc),  a  group  of 
engineers  in  both  government  and  industry  to  service  those 
ilities.  This  in  turn  created  a  series  of  tasks  and  procedures  to 
be  accomplished  and  a  set  of  documents  to  be  prepared  The 
ilities  were  procedure  driven  (often  based  on  overly  simplistic 
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ARN-118  Maintenance  Experience 
Figure  1 


assumptions),  requiring  an  inordinate  amount  of  data,  and 
resulting  in  an  mconsistent  product. 

Early  on.  aircraft  had  three  basic  systems  which  were 
mechanical  in  nature;  the  aircraft  structure,  the  engine  and  the 
flight  controls.  Preventative  maintenance  was  used  to 
preclude  the  failure  of  this  critical  equipment  dunng  flight. 

The  aircraft  structure  was  covered  with  cotton  or  hnen  fabnc 
that  deteriorated  over  time,  and  it  had  to  be  replaced.  When 
t.  is  occurred,  the  aircraft  was  stripped,  and  the  structure 
rebuilt  to  mauitain  safety  throughout  the  life  of  the 
replacement  cover.  The  engine  was  disassembled,  inspected 
and  overhauled  based  upon  a  recommended  time  between 
overhaul.  Preventative  maintenance  was  applied  for  military 
aircraft  and  was  requited  by  Civil  Aeronautics  Agency  (CAA, 
the  predecessor  of  todays  Federal  Aviation  Administration) 
regulations  for  civil  aircraft  Even  though  the  basic  design  of 
aircraft  evolved  (moving  from  fabric  covered  structure  to  all 
metal  monocoque  design)  the  process  continued  for 
commercial  aumft  until  the  mid-1950s  when  they  moved 
toward  the  phased  inspection  process.  The  regulations 
requiring  annual  and  one-hundred  hour  inspections  still  apply 
for  our  general  aviation  fleet 

After  World  War  n,  commercial  aviation  advanced  very 
rapidly.  During  the  late  1940s  and  early  19S0s  the  airlines 
observed  that  some  (possibly  many)  of  the  required 
inspections  were  being  done  for  arbitrary  reasons.  United 
Airlines,  working  in  conjunction  with  the  CAA  and  the 
aiicrafl/engine  manufacturers,  developed  a  procedure  which  is 
known  in  the  military  as  Reliability  Centered  Maintenance. 
This  included  a  logic  process  and  a  series  of  criteria  Safety 
Critical,  Mission  Critical,  Major  Econottuc  Impact  and 
Durability  Critical)  that  are  based  upon  the  consequences  of 
failure  and  can  be  used  to  select  the  appropriate  maintenance 
(preventative,  corrective,  or  opportunistic)  procedure  for  each 
piece  of  airborne  equipment  This  logic  process  applies  to 
avionics,  although  not  commonly  implemented  and  is  defined 
in  MiL-STD-1343,  Rtliability-ctnicr^  Mainlcnancc  for 
Aircraft.  Engines  and  Equipment  published  in  February  1985. 

The  first  avionics,  airborne  radios,  were  installed  in  the  mid- 
193()s.  At  this  time,  they  were  “nice  to  have,”  but  were  not 


essentia!  to  the  performance  of  the  mission.  This  attitude 
continued  through  World  War  II  and  >nto  the  early  1950s, 
when  the  Air  Traffic  Control  System  was  established  and  tlie 
operation  of  aircraft  during  Instrument  Meteorological 
Conditions  became  common  place.  As  a  result, 
communication  and  radio  navigation  equipment  were  then 
considered  mission  essential.  With  the  introduction  of  the 
radar  based  weapons  delivery  system  on  the  F-105  aircraft  in 
the  mid-1950s,  the  avionics  became  Mission  Critical.  More 
recently,  avionics  such  as  the  fly-by-wire  system  on  the  F-16, 
and  Terrain  Followingfreirain  Avoidance  systems  have 
become  Safety  Cntical  functions.  Avionics  now  constitutes  a 
third  of  the  fly  away  cost  of  a  modem  fighter  aircraft  and 
performing  numerous  mission  and  safely  critical  functions. 

In  the  1940s,  Avionics,  and  their  development  processes  were 
in  their  infancy.  Often  the  development  process  was  unique  to 
the  manufacturer,  and  possibly  to  the  individual  designer. 
Some  manufacturers  characterized  the  life  of  their  pans  under 
specified  conditions,  and  reported  the  results  in  the  literature. 
Some  designers  did  extensive  thermal  analysis  in  order  to 
minimize  the  degradation  of  their  electronics  (tube  type 
equipment  operated  quite  hot).  Still  others  did  testing  to 
determine  the  failure  rates  of  their  pans. 

During  the  late  1940  and  early  1950s,  a  series  of  specifications 
forelecironic  parts  were  developed.  They  addressed 
performance  and  test  requirements,  but  not  in  a  consistent 
fashion.  A  consensus  on  the  appropriate  content  and 
verification  procedures  to  be  included  in  the  piece  pan 
specifications  had  not  yet  developed.  In  1952,  The  Advisory 
Group  on  Reliability  of  Electronic  Equipment  (AGREE) 
Committee  was  formed  to  establish  order.  The  committee  was 
made  up  of  representatives  of  the  Office  of  the  Assistant 
Secretary  of  Defense  (Engineering),  the  Office  of  the  Assistant 
Secret'  ry  of  Defense  (Supply  and  Logistics),  plus  the  Army, 
Navy ,  nd  Air  Force.  This  committee  worked  on  the  problem 
for  five  years  and  ultimately  issued  the  AGREE  Report  in 
1957. 

The  AGREE  Committee  report  considered  the  application  of 
life  laws,  statistical-based  reliability  predictions  and  testing 
techniques  along  with  the  application  of  preventative  and 
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corrective  maintenance  policies  to  avionics.  However,  the 
committee  ultimately  recommended  that  life  requirements  be 
defined  as  a  Minimum  Acceptable  Reliability  expressed  as  a 
MTBF.  They  also  recommended  the  establishment  of 
lequuements  for  reliability  tests  using  developmental  models, 
pilot  producuon  and  production  model  equipments.  The 
report  went  on  to  recommend  a  major  overhaul  of  the 
electronic  parts  and  components  specification  and 
qualification  process  and  supported  government  interaction  in 
the  process.  The  report  identified  requirements  for  the 
packagmg  ot  electronic  devices/equipment  prior  to  storage  or 
shipment,  mandated  the  application  of  coirecnve  maintenance 
and  recommended  the  implementation  a  statistically  based 
reliability  program. 

These  decisions  responded  to  the  need  ior  a  soluuon  that  was 
supportable  within  the  existing  technology  and  could  be 
implemented  quickly.  Over  the  past  thirty  yean,  since  the 
AGREE  Commtnee  completed  their  work,  there  have  been 
tremendous  advances  in  the  analytical  tools  and  computational 
power  available.  In  1937,  the  primary  tool  available  to  the 
engineer  was  the  slide  rule.  Main  frame  computers  were  just 
entering  service  in  the  universines  and  were  not  yet  common 
place  in  the  industry;  computer  time  was  still  carefully 
rationed.  The  common  use  of  a  scientific  hand  held  calculator 
was  still  fifteen  years  away.  Thus,  by  necessity,  the  methods 
needed  to  reach  a  solution  had  to  be  rather  simple  by  todays 
standards. 

Over  time,  the  recommendations  contained  in  the  AGREE 
Report  evolved  into  the  MU--STD-785,  Reliability  Program 
for  Systems  and  Equipment  Development  and  Production. 

This  document  contains  a  senes  of  tasks,  that  were  thought  to 
ensure  that  the  resulting  product  would  fulfill  operational 
needs.  These  requirements  have  been  mandated  for  most 
DOD  procurements  since  the  introduction  of  MIL-STD-785. 

Inherent  m  the  implementation  of  the  MIL-STD-785,  the 
reliability  prediction  procedure  contained  in  MIL-HDBK-217, 
ReliabUitv  Prediction  of  Electronic  Eaumment  was  mandated 
(see  Appendix  A  for  further  discussion  of  the  reliability 
prediction  procedure).  With  this  understanding,  the  life  testing 
and  part  charactenzation  efforts  that  some  manufacturers  were 
accomplishing  ceased,  since  it  was  no  longer  considered 
valuable  by  their  military  customers. 

MIL-STD-785 


There  has  been  considerable  discomfort  with  R&M  and  the 
way  it  is  applied  to  our  programs,  the  effort  involved,  the  cost 
of  the  effort  and  the  inconsistency  of  results.  However,  few  of 
us  have  taken  the  time  to  understand  how  the  R&M  program 
evolved,  its  implementation,  its  impacts  on  the  product  and  the 
govemment/industry  motivations 

Appendix  A  addresses  several  of  the  R&M  Program  tasks, 
then  background,  and  the  problems  with  their  application  to 
modem  avionic  systems.  This  should  provide  an 
understanding  of  the  R&M  Programs  short  comings  and  why 
it  does  not  consistently  yield  a  product  that  satisfies  our  users 
needs  and  outlines  several  reasons  a  major  change  in  direction 
is  needed. 

Avionics/Electronics  Integrity  Program  (A VIP) 

Aeronautical  Systems  Division  (ASD),  the  largest  of  the  US 
Air  Forces  acquisition  divisions,  has  implemented  a  systems 
engineering  process  for  the  development  of  avionic  and 
electronic  equipment.  The  process  is  based  upon  their 
experience  with  the  Aircraft  and  Engine  Structural  Integrity 
Programs  (ASIP  and  ENSIP)  which  have  proven  to  be  veiy 
successful  in  achieving  functional  performance  and  protection 
safety.  These  programs  are  based  upon  an  understanding  of 
the  stresses  and  related  stress  cycles  the  aircraft  or  engine  will 
experience  over  its  operational  life.  They  examine  the  physics 
of  failure  and  works  towards  a  design  process  whose  objective 
IS  to  preclude  in-flight  failure  rather  than  limiting  the  failure 
rate.  Both  ASIP  and  ENSIP  involved  major  changes  the  logic 
process  used  during  design.  ASIP  was  initiated  in  response  to 
a  series  of  in  Bight  structural  failures  which  resulted  in  the  loss 
of  the  aircraft,  and  all  too  often  to  the  loss  of  life.  ENSIP 
applied  the  same  logic  process,  tailored  for  application  to 
aircraft  engines. 

Traditional  Reliabdity  and  Maintainability  (R&M)  and  AVIP 
are  similar  in  that  their  objectives  are  the  same: 

To  focus  attention  on  the  need  to  improve  reliability. 

However,  there  are  several  significant  differences  as  outhned 
in  Table  1  below: 


AVIP 

•  Process  Driven 

•  Recognizes  Failures  are  Deterministic 
Based  on  Cause  and  Effect  Engineering 

•  Allows  Preventative  Maintenance 
Options 

-  Opportunistic 

-  Collective 

•  Functional  Performance  Protected  by: 

-  Design 

-  Maintenanee  Procedures 

-  Redundancy 

•  Installed  Environments 

Freedom  to  Select  Processes  that  Fulfill 
Functional  and  Life  Requirements 

•  Qualification  Based  upon  Accelerated 
Life  Test 


•  Activity  (Task)  Orientation 

•  Assumes  Failures  are  Random 

•  Mandates  Corrective  Maintenance 


•  Functional  Performance  Protected  by 
Redundancy 


•  MIL-Spec  Environments 

-  MIL-Spec  Processes 

•  (Qualification  Based  upon  Statistical  Sample 


Table  1 


1 


I 
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The  AVIP  Process 
Figure  2 


The  AVIP  development  process  begins  with  a  detailed 
understanding  of  how  the  equipment  will  be  used  m  operauon 
and  the  ramifications  of  the  various  support  decisions.  This 
not  oniy  includes  the  number  of  operating  hours,  but  such 
usage  factors  as  the  number  of  turn  on/off  cycles,  mode 
changes  or  transmit  cycles,  etc,  that  affect  the  life  of  the 
equipment.  The  process  also  necessitates  an  understanding  of 
the  enviionments  the  equipment  wiil  experience  as  a  part  of 
the  manufacturmg  and  testing  process  prior  to  delivery,  during 
transportation,  while  installed  in  the  aircraft  (both  on  the 
ground  and  in  the  air)  and  whiie  being  repaued.  Environments 
that  are  addressed  include  electromagnetic  interference  and 
electric  power  variations,  as  well  as  the  usual  temperature, 
altitude,  vibration,  humidity,  sand  and  dust,  etc.  This  allows 
the  designer  to  take  into  account  the  cumulative  effect  of  the 
stresses  and  stress  cycles  the  equipment  must  endure  over  it’s 
operational  life. 

Matenals  Charactenzation  is  a  term  used  to  desenbe  the 
development  of  a  fundamental  understanding  of  the  properties 
of  each  of  the  materials  and  parts  that  are  to  be  used  in  the 
design,  their  failure  mechanisms  and  the  effects  of  ailowable 
vanations  (chemical,  metallurgy,  dimensions,  flaws,  etc..)  in 
those  matenals.  The  process  recognizes  that  failures  are 
largely  deterministic  in  nature  Failures  occur  as  a  result  of 
the  products  physical  configuration,  the  stress  concentrations, 
the  magnimde  and  location  of  the  flaws  allowed  in  the 
product,  and  the  cumulative  damage  from  the  stresses  and 
stress  reversals  that  occur  over  the  equipments  life. 

The  fatigue  life  of  these  materials  is.  in  large  pan.  determined 
by  the  metallurgy  and  physical  dimensions  at  locations  such  as 
solder  joints,  plated  through  holes,  vias  and  interconnects 
within  printed  wiring  boards  lead  wires,  etc^.  Within  the 
electronic  pans,  fatigue  is  also  the  life  limiting  failure 
mechanism  of  the  attachment  of  the  silicon  chip  to  the  case^. 
The  life  of  an  aluminum  conductor  internal  to  the  pan  is 
determined  by  the  impurities  within  the  aluminum,  the  groin 
structure  of  the  aluminum,  barrier  metals,  the  cross  section  of 
the  conductor  as  well  as  current  and  temperature  stress'*. 

These  charactenstics  are  in  turn  determined  by  the  applicattoi'. 


manufactunng  process  and  the  dimensional  tolerances.  Time 
dependent  dielectric  breakdown  is  again  controlled  by  the 
material  properties,  physical  dimensions  and  allowable  time, 
temperature  and  current  stress^  There  are  postulated  life  laws 
in  the  literature  for  each  of  these  failure  mechanisms. 

However,  none  of  these  life  laws  have  not  been  endorsed  by 
the  industry  as  a  whole.  A  great  deal  of  wotk  has  been,  and 
conunues  to  be  done  evolving  these  models. 

During  the  design  process,  more  emphasis  is  needed  in  the 
application  of  material  characteristics  to  design.  Examples 
include;  coefficients  of  expansion,  fatigue  life,  arcing  and 
cracking  of  dielectric  materials,  strength,  etc.  These 
characterisdes,  and  the  process  controls  that  are  applied  during 
manufacture  to  protect  life,  should  be  used  to  establish  design 
criteria  that  will  be  applied  during  design.  This  understanding 
will  warrant  greater  freedom  in  the  selecdon  of  parts,  materials 
and  processes;  thus  allowing  relief  from  many  of  the 
government  mandated  specification  requirements  such  as 
those  contained  in  MlL-E-5400,  MlL-STD-454.  etc. 

The  design  team  is  expected  to  ensure  that  fundamentai 
mechanical  and  thermal  analysis  are  accomplished  prior  to  the 
release  of  drawings,  when  changes  can  be  incorporated  with 
rclauve  ease.  This  may  weli  be  an  iteradve  process,  ensuring 
die  design  fulfills  each  of  the  requued  design  constraints. 

The  application  of  fatigue  theory  to  the  design  may  also  allow 
the  implementation  of  a  preventative  maintenance  policy  to 
address  many,  if  not  all,  of  the  failure  mechanisms  that  might 
occur.  Many  of  the  basic  analytical  tools,  such  as  those 
addressed  in  Mr.  Dave  S.  Steinberg’s  books.  Cooling 
lechnioues  for  Electronic  Equipment  and  Vibrauon  Analysis 
for  Electronic  Equipment.  These  tools  have  been  available  for 
almost  twenty  years,  and  have  been  applied  by  some  designers 
as  a  normal  part  of  their  design  practice.  They  are  also 
frequently  applied  after  the  fact  when  equipment  encounters 
problems  with  required  tests  or  dunng  operation.  These  tools 
should  be  used  to  avoid  problems,  rather  than  fix  problems 
when  the  development  schedule  is  in  jeopardy  and  design 
altcmadves  are  limited. 
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Mr.  Steinberg,  in  his  nanerTmls  Available  for  Imnlemeniing 
AVIP  (Attachment  B)  offered  an  analytical  life  piediction 
approach  that  can  be  accomplished  using  a  hand  held 
calculator  for  lead  wires  and  solder  joints.  New,  computer 
aided  design  tools  are  becoming  available  which  will  make  the 
analytical  effort  less  time  consuming,  more  user  hnendly  and 
allow  more  aggressive  designing. 

Development  of  the  manufacturing  processes,  process  limits, 
environmental  stress  screen/proof  tests  when  appropriate,  and 
inspection/veriftcation  techniques  are  an  integnd  pan  of  the 
development  effort.  The  effectiveness  of  the  manufacturing 
process  limits,  quality  controls,  life  charactenstics  and  the 
over  all  suitability  of  the  design  will  be  demonstrated  in  an 
durability  life  test  using  combined  environments,  simulating 
operational  use  (tum-ons,  mode  changes,  repair  cycles,  etc.) 
and  applying  the  proposed  maintenance  procedures  over  the 
life  of  the  equipment  The  test  may  also  replace  major 
portions  of  the  tradidonal  engineering  qualifieation  test  by 
including  excursions  to  the  extreme  environmental  limits  in 
the  test  profile. 

The  remaining  environments  not  addressed  by  the  accelerated 
life  test  should  be  demonstrated  by  inidating  the  appropriate 
pordons  of  a  tradidonal  engineering  qualidcadon  test  Only 
after  sadsfactory  compledon  of  the  vcrificadon  process,  and 
the  demonstradon  of  opcradonal  utility,  will  the  equipment  be 
ready  for  produedon  release. 

Since  the  equipment  has  been  designed  using  a  fadgue  theory, 
and  our  users  are  always  changing  the  way  they  use  their 
equipment,  one  can  then  apply  the  same  analytical  tools  to 
adjust  the  life  expectadons,  maintenance  intervals,  and 
andcipate  the  ne^  for  modlHcadon  before  an  unsupportable 
situadon  results.  This  can  be  achieved  by  repeating  the  key 
analysis  done  during  design,  but  with  revised  design  usage  and 
environmental  data.  This  analysis  could  be  incorporated  in  a 
life  management  computer  algorithm  which  would  allow  the 
supporting  community  to  keep  track  of  the  life  expended  by 
the  equipments  over  dme,  and  facilitate  the  orderly 
management  of  the  equipment  based  upon  technically  sound 


The  offeror  is  encouraged  to  tailor  the  draft  Statement  of 
Work,  provided  as  a  part  of  the  solicitation,  to  include  any 
tasks  required  to  complete  the  specificadon,  and  to  include  in 
the  Systems  Engineering  Master  Schedule  (SEMS)  the 
milestone  indicating  when  the  task  will  be  accomplished.  The 
SEMS  is  an  event-driven  document  where  the  contractor 
establishes  criteria  for  the  satisfactory  completion  of  each 
major  program  milestone.  For  example,  at  the  Critical  Design 
Review,  the  contractor  might  commit  to  the  compledon  of  a 
fully  released  drawing  package,  completion  of  thermal, 
vibration,  fangue  analysis,  the  availability  of  draft  test 
procedures,  etc..  Before  these  milestones  can  be  considered 
complete,  an  agreement  must  be  reached  between  the 
conuactor  and  their  customer. 

The  procuring  activity  evaluates  the  various  offeror’s 
proposal,  and  makes  a  selection  based  upon  pre-established 
standards.  Thus,  the  offeror  is  made  an  active  participant  in 
the  requirements  definition  process,  has  developed  ownership 
of  those  requirements,  and  is  expected  to  successfully 
implement  the  process  after  contract  award. 

The  application  of  the  AVIP  design  process  allows  one  to 
mr-'c  toward  avionic  designs  that  will  operate  for  a 
predictable  period  of  ome,  number  of  cycles,  or  other 
measurable  characteristic  with  a  reasonable  probability  of 
success.  This  makes  it  possible  to  move  from  an  on  demand 
(corrective)  approach  to  maintenance  to  a  preventative  or 
opportunistic  maintenance  concept  where  appropriate.  The 
decision  process  should  be  based  on  the  consequences  of 
allure:  safety,  the  ability  to  accomplish  the  mission  and 
economics.  The  decision  process  for  airftames  and  engines  is 
contained  in  MIL'STD-1843  can  be  applied  to  aviomes  as 
well. 

Thus,  the  Avionics  Integrity  Program  embodies  and  effecn  /e 
systems  engineenng  process  which,  when  applied,  will  result 
in  equipment  that  fulftlls  both  functional  performance  and  life 
expectations,  and  can  be  effectively  managed  in  the  field. 

General  Discussion  of  Conflicts: 


The  application  of  the  AVIP  in  conjunction  with  a  system 
engineering  development  process  provides  the  equipment 
manufacturer  much  more  freedom  than  has  been  allowed  in 
the  past.  This  includes  the  opportunity  to  establish  the  dates 
for  major  program  milestones  such  as  Systems  Requirement, 
Preliminary  Design,  and  Critical  Design  Review.  The 
manufacturer  is  also  relieved  of  much  of  the  government 
mandated  specification  tree  (how  to’s)  and  documentation 
requirements.  The  output  of  the  process  (within  the 
manufacturer's  capability  to  undentand  the  failure  processes 
and  the  ability  to  control  the  key  material  parameters),  will  be 
avionic  equipment  that  has  a  known  minimum  life  with  a 
given  design  usage  and  environments. 

The  basic  requirements  for  the  Avionics  Integrity  Program  are 
contained  in  MIL-A-87244  which  is  a  performance 
specification  written  in  MIL-PRIME  iotmat  A  MIL-PRIME 
specification  is  structured  in  a  way  that  requires  tailoring,  and 
has  attached  a  handbook  which  guides  the  user  through  the 
tailoring  process.  Each  of  the  requirements  contain  a  blank 
that  may  be  filled  in  by  either  the  procuring  activity  prior  to 
the  release  of  the  solicitation,  defined  by  the  offeror  as  a  part 
of  his  proposal,  or  determined  as  a  result  of  a  task  (analysis, 
survey  or  test)  that  is  to  be  accomplished  as  a  part  of  the 
contracted  effort. 


Any  effort  to  change  the  way  one  does  business  can  not  occur 
in  a  vacuum.  AVIP  has  to  be  incorporated  in  a  way  that 
allows  it  to  be  accommodated  within  the  existing  ftamework 
of  policies,  procedures  and  regulations  where  possible. 
Unfortunately,  such  an  approach  involves  compromises,  raises 
potential  conflicts  and  huidles  that  need  to  be  addressed  and 
surmounted.  At  times,  it  requires  making  compromises, 
incorporating  some  new  concepts  while  delaying  the  adoption 
of  others,  all  the  while  applying  consistent  pressure  to  embrace 
the  total  process.  Both  ASIP  and  ENSIP  experienced  a  similar 
birthing  process  and  took  over  ten  yean  to  complete. 

Each  of  the  individuals  and  organizations  affected  by  the 
change  has  a  different  perspective  which  results  in  conflicts. 

It  should  be  recognized  that  the  AVIP  process  and  each  of  the 
practicitioners  (both  organizations  and  individuals)  will  under 
go  a  series  of  changes  as  the  implementation  matures.  It 
should  be  recognized  that  organizational  inertia  will  tend  to 
maintain  the  status  quo  no  matter  how  badly  the  change  is 
needed.  However,  consistant  managerial  support  and  sound 
engineering  will  prevail. 

As  one  looks  at  the  change  from  the  acquisition  communities 
perspective,  there  are  several  difficult  problems  that  must  be 
addiused.  There  are  those  who  believe  that  if  the  decision 
makers  would  issue  a  written  policy,  the  change  would  be 
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accomplished  with  lelative  ease.  Others  believe  the 
individuals  who  are  to  implement  the  process  have  to  "buy 
into"  or  “take  ownership"  of  the  process  or  the  process  will 
fail.  The  process  has  to  evolve  over  time,  to  b;  tailored  with 
each  new  application  in  order  to  take  advantage  of  unique 
experiences  offered  by  each  new  participant. 

From  a  program  managen  point  of  view,  he  wants  to  know 
how  the  process  can  be  implemented  with  the  available 
resources  and  time  constraints.  He  also  needs  to  understand 
that  engineering  is  committed  to  provide  the  needed  technical 
support,  and  he  must  feel  comfortable  that  the  engineers 
comprehend  what  is  bemg  asked  of  them.  There  is  a  need  to 
know  that  the  product  will  be  accepted  by  the  user,  the 
supporting  command,  and  that  the  process  will  be  adopted  by 
the  industry.  Further,  he  needs  to  feel  comfortable  with  the 
way  the  product  will  be  evaluated  during  independent  and 
operational  testing. 

The  engineers  and  logisticians  are  concerned  that  process  may 
not  be  sufTicienlly  mature  to  warrant  its  application.  They 
want  to  fee!  comfortable  with  their  stags’  skills  (or  their 
ability  to  develop  them),  and  that  they  are  prepared  to  buy  into 
the  concept,  their  new  roles  and  responsibilities.  The 
logisticians  ore  also  concerned  that  the  process  uses  different 
metrics,  unfamiliar  ones,  which  cannot  be  used  directly  in 
their  current  Logistics  Support  Analysis  process.  They  ate 
bothered  by  the  thought  of  preventative  maintenance  on 
avionics  which  rans  counter  to  thirty  plus  years  of  experience. 

Procurement  is  anxious  to  learn  how  requirements  can  be 
adequately  defined  in  contracmal  terms,  how  offerors  can  be 
airly  evaluated,  how  the  effort  can  be  appropriately  priced  and 
that  the  effort  has  a  definitive  conclusion. 

The  users  of  standard  avionics  include  the  US  Air  Force 
(.Strategic  Air  Command,  Tactical  Air  Command,  etc.).  Army. 
Coast  Cuard,  Marines,  Navy  and  allies.  They  need  to  feel 
comfortable  that  the  product  will  fulfil  their  needs,  that  they 
can  accommodate  the  necessary  changes  in  the  way  they 
operate  and  maintain  their  systems,  its  effect  on  their 
maintenance  planning,  manpower  needs  and  readiness. 

From  an  industry  stand  point,  the  aircraf .  primes  want  to 
understand  what  they  are  being  asked  to  do,  that  their  staff  has 
or  can  develop  the  skills  necessary  to  do  it  within  the  time 
available,  that  the  necessary  information  and  tools  are 
available  and  that  their  suppliers  are  capable  and  willing. 

From  the  original  equipment  manufacturers  (OEM) 
standpoint,  they  want  to  feel  comfortable  that  their  staff  has 
the  skills  necessary  to  accomplish  the  effort,  the  time  allowed 
IS  reasonable,  they  can  accurately  cost  the  effort,  the  selection 
process  will  be  fair,  the  risk  acceptable,  their  suppliers  will 
support  and  that  their  participation  will  not  adversely  affect 
future  business. 

The  part  vendors  are  concerned  that  their  participation  will 
necessitate  the  release  of  information  on  their  processes, 
information  that  propnetary,  information  that  has  provided 
them  a  competitive  ^ge,  and  liiat  leakage  to  them  competitors 
will  not  occur. 

Spedfle  Conflicts: 

Standard  Environments  verses  Specific  Design  Usage, 
Instailed  Environments,  Storage,  etc. 

The  environmental  requirements  for  standard  avionics  are 


established  by  reference  to  MlL-E-i400,  Electronic 
Equipment,  Aerospace,  General  RequiiemenLs  for  for  Class  II 
equipment  and  MlL-STD-810,  Environmental  Test  Methods 
and  En.gineering  Guidelines.  MIL-STD-810  defines  specific 
test  requirements  or  vibration,  shock,  humidity,  sand  and  dust, 
etc.  which  have  been  used  for  the  engineering  qualiftcation  of 
the  avionics.  Earlier  versions  of  MIL-STD-810  contained 
limits  for  vanous  environments  (i  e.  vibration)  for  different 
categories  of  environments  such  as  "uninhabited  fighter”, 
"inhabited  cargo",  etc. 

The  current  release  of  MIL-STD-810  instrticts  the  user  to 
determine  the  environments  at  the  installed  location  for  the 
equipment  and  use  the  installed  environments  during  test,  but 
provides  default  values  for  the  previous  categories.  Often, 
these  default  values  are  used.  This  practice  has  resulted  in 
numerous  problems  when  the  equipment  is  actually  integrated 
into  the  aircraft.  Several  progam  offices  at  ASD  have 
encountered  instances  where  the  environmental  requirements 
contained  in  MIL-E-54(X)  and  the  default  values  in  MIL-STD- 
810  have  been  greatly  exceeded,  resulting  in  major  reliability 
problems,  long  program  delays  and  cost  growth. 

An  example  of  this  type  of  problem  occurred  with  the 
L.\NTIRN  (Low  Altitude  Night  Targeting  Infra-red 
Navigation)  System.  This  system  was  developed  using  the 
environmental  conditions  now  identitied  as  default  conditions 
in  MIL-STD-8 10  as  the  design  requirements.  When  flight 
testing  began,  an  inordinately  large  number  of  failures  were 
encountered  on  the  Navigation  Pod.  The  preponderance  of 
these  problems  resulted  from  the  failure  of  solder  joints 
attaching  Icadless  chip  carriers  to  the  printed  wiring  boards 
due  to  exposure  to  vibration  and  acoustic  noise.  When  the  an 
instrumented  pod  was  installed  on  the  F-16  and  flight  tested, 
the  actual  environments  exceeded  those  called  up  out  in  MIL- 
STD-810  by  more  thanlO  db.  These  problems  placed  the 
program  in  jeopardy  of  being  cancelled.  Correcting  these 
problems  resulted  in  a  major  schedule  slippage  with  an 
attendant  increase  in  cost.  To  alleviate  this  problem,  a 
complete  mechanical  redesign  of  the  printed  winng  boards 
contained  in  several  line  replaceable  units  was  necessary.  A 
highly  automated  manufacturing  process  with  very  close 
statistical  process  control  was  established  in  order  to  achieve 
the  needed  consistency  in  the  product.  With  these  problems 
being  resolved,  the  resulting  system  perforaied  extremely  well 
as  demonstrated  dunng  the  Persian  Gulf  War. 

When  equipment  is  designed  based  upon  the  design  usage,  and 
the  installed  environments,  as  addressed  by  MlL-A-87244, 
these  problems  are  avoided.  However,  this  task  involves 
technical,  managerial  and  contractual  challenges.  Often,  a 
survey  of  the  environment  was  not  accomplished  during  the 
flight  test  of  the  aircraft  or  the  data  can  no  longer  be  found.  If 
the  data  is  available,  it  may  no  longer  be  appropriate  because 
the  environments  may  have  changed  as  a  result  of  aircraft 
modifications.  Changes  in  the  avionics  suite  may  result  in 
different  heat  loads  on  the  cooling  system,  ambient 
temperatures  in  the  avionics  bays,  resonant  frequencies  of  the 
mounting  shelves  as  the  mass  of  the  equipment  changes,  etc. 
Thus,  one  should  understand  the  limitations  of  available  data. 
However,  the  data  is  worth  considering. 

When  standard  equipment  is  bought,  it  is  typically  purchased 
from  an  avionics  supplier  rather  than  an  aircraft  prime.  The 
aircraft  prime  may  have  useful  data  which  is  not  available  in 
government  archives.  In  this  case,  the  avionics  supplier  could 
purchase  the  data  from  the  aircraft  prime  as  a  part  of  the 
development  effort 
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There  are  also  analytical  techniques  that  are  used  to  estimate 
the  environments  in  a  new  aircr^t  before  it  is  ever  built. 

These  techniques  take  into  account  the  rigidity  of  the  aircraft 
structure,  proximity  of  the  equipment  to  rotating  machinery 
such  as  the  engine,  the  operating  frequencies  of  the  machinery, 
lever  arms  about  the  center  of  gravity,  etc.  These  analysis 
techniques  could  be  used  for  retrofit  applications  as  well.  The 
aircraft  prime  contractors  are  well  versed  in  the  application  of 
these  techniques 

Rome  Air  Development  Center  has  developed  a  Time-Stress 
Measuring  Device  that  can  be  ir'talled  at  a  estimation  of  the 
environments.  The  first  generaoon  of  these  devices  are  about 
the  size  of  two  packs  of  king  size  cigarettes,  has  a  self- 
contained  battery,  and  can  store  several  weeks  of  data.  These 
units  have  been  tested  on  A-7  and  A-10  aircraft.  With  the 
cooperation  of  the  user,  similar  units  could  be  installed  on 
operational  aucraft  and  the  data  collected.  This  data  could 
then  be  extrapolated  to  the  limits  of  the  aircraft  operating 
envelope  and  atmospheric  conditions  and  used  for  design. 

For  the  .Mark  XV  Combat  Identification  System,  the 
government  recognized  that  Line  Replaceable  Units  would 
move  from  aircraft  to  aircraft  over  their  life.  Using 
engineering  udgement,  a  series  of  core  aircraft  were  selected 
that  were  thought  to  be  most  representative  of  the  total  fleet. 
The  environments  in  these  vehicles  were  then  used  to  develop 
a  composite  environmental  profile  that  was  to  be  used  in  the 
Mark  XV  design  and  veriftcadon  process.  When  the 
equipments  are  installed  on  vehicles  which  were  not  a  part  of 
the  core,  the  modification  agency  would  be  required  to  ensure 
that  the  installed  environments  are  no  worse  than  those 
verified  for  the  cote  platforms,  or  modificaoons  accomplished 
to  bring  the  environments  within  limits.  It  is  also  possible  to 
install  the  equipment  and  accept  the  nsk  that  acceptable  life 
characteristics  will  not  be  attained  (basically,  this  is  what  is 


done  when  one  uses  MIL-E-.*i4(X)  requirements  and  MIL-STD- 
8 10  default  conditions  today) 

Standard  verses  Application  Specific  Parts: 

Another  source  of  conflict  results  fiom  the  imposition  of  the 
order  of  precedence  of  MIL-Specs  contained  in  MIL-STD- 
454,  Standard  General  Requuements  for  Electronic  Equipment 
and  the  MIL-STD-965  Parts  Control  Program  (see  Appendix 
A  for  further  discussion  of  pans  control  procedures)  These 
requirements  direct  the  use  of  sla..:lard  parts  in  the  design,  and 
manufacturer  of  avionics.  Standard  pans  are  manufactured 
and  tested  in  accordance  with  government  published  general 
and  detail  specifications  such  as  MIL-M-3SSI0,  General 
Military  Specification  for  Microcircuits. 

These  specifications  are  structured  to  promote  multiple 
sources  for  each  standard  device  type.  To  this  end,  many 
fundamental  characteristics  of  the  devices  allow  very  wide 
limits/tolerances  on  key  parameters  and  some  may  not  be 
addressed  at  all.  The  intent  is  to  permit  pans  from  different 
vendors,  using  different  materials  and  manufacturing 
processes  to  supply  parts  under  the  same  standard  part  number 
that  are  supposedly  interchangeable.  The  process  of 
coordinating  the  detail  specification  between  several  suppliers 
results  in  a  least-common-denominator  set  of  clectncal 
parameters.  Allowed  variabilities  include  die  attachment 
materials,  bond  wire  materials,  dielectric  layer  material  and 
dimensions,  etc.  As  an  example,  the  variations  allowed  in  the 
mechanical  configuration  of  a  Dual  In-line  Package  (DIP) 
microcircuit  per  MIL-M-38510,  includes  three  different  lead 
frame  configurations  (see  Figure  3),  eight  different  base  metal 
alloys  for  the  leads  frame  and  four  different  lead  plating 
structures. 

Figure  4  shows  the  allowable  dimensional  allowable  variations 
of  the  iead  frame  configurations  for  a  DIP. 
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Allowed  Variability  Within  Mil-M-38510H 
Figure  3 
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Tolerance  in  DIP  Lead  Wires 
Figure  4 
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Mil  Spec  Tolerances  Cause  Life  Vanability 
Figures 


Figure  5  depicts  the  effects  of  the  variability  allowed  in  the 
lead  wire/lead  frames  of  MIL-Spec  parts.  The  calculated 
variation  in  the  fatigue  life  resulting  from  the  10  percent 
tolerance  of  a  circular  lead  wire  such  as  those  used  on  a 
transistors,  resistors  and  capacitors  varies  by  a  factor  o."  13  to 
1  The  lead  frames  for  integrated  circuits  contained  m  both  the 
flat  pack  and  DIPs  encounter  both  bending  and  twisting 
motions  as  the  parts  are  subjected  to  temperature  cycling  and 
vibration.  For  a  flat  pack  manufactured  with  the  maximum 
allowable  and  minimum  allowable  dimensions,  the  fatigue  life 
can  vary  by  a  factor  of  3300  to  1  in  bending  mode.  Similarly, 
the  fatigue  for  a  DIP  can  vary  by  a  factor  of  70, 0  to  1  for  the 
configuration  shown  in  Figure  4.  In  this  case,  the  allowable 
variation  in  fatigue  life  of  these  leads  exceeds  the  total  number 
of  major  thermal  cycles  that  avionic  equipments  would  be 
expected  to  experience  over  its  life  when  installed  on  a 
modem  fighter  aircraft  such  as  the  F-16.  The  situation 
becomes  much  worse  when  the  other  allowable  lead  frame 
configurations  and  materials  are  considered. 

When  ordering  standard  parts,  any  of  the  allowed  variations 
may  occur  in  the  delivered  product.  Because  one  production 
lot  exhibits  appropnate  functional  performance  and  life 
charactensucs  in  a  particular  application  does  not  ensure  that 
the  next  lot  from  the  same  manufacturer  or  a  part  with  the 
same  part  number  from  a  different  manufacturer  will  also  meet 
expectations. 

There  has  been  a  trend  to  use  more  and  moe  rpplicaiion 
specific  parts  withm  new  avionic  designs  in  order  to  achieve 
the  requued  functional  performance  within  the  available  size 
and  weight  constraints.  As  the  implementation  of  AVIP 
progresses,  there  will  be  increased  pressures  to  use  more  and 
more  .application  specific  parts.  To  some  degree,  this  allows 
the  customer  to  take  greater  control  over  the  parts  that  arc 
purchased.  However,  part  vendors  may  resist  this  increased 
customer  involvement  for  several  reasons.  Prst  of  all,  the 
OEMs  have  been  asking  for  a  great  deal  of  information  with 
out  understanding  how  they  were  going  to  use  the  infonnaiion. 
The  part  vendors  are  reluctant  to  provide  detail  on  their  design 
and  manufacturing  processes  without  a  clear  understanding  of 
how  It  is  going  to  be  used.  Further,  they  are  concerned  the 
requested  infonnation  may  give  away  secrets  that  are  the  key 


to  their  competitive  edge.  There  may  be  some  relief  from  this 
concern  as  the  Qualified  Manufacturer  List  concept  which  has 
been  initiated  by  RADC  and  DESC  by  making  the  part 
vendors  process  control  data  visible. 

Redundancy  verses  Robust  Design  and  Preventative 
Maintenance 

Tradiuonally,  redundancy  has  been  used  to  protect  safety  and 
mission  reliability.  With  tlie  implementation  of  AVIP, 
redund'hcy  is  required  to  protect  safely  cmical  functions, 
while  robust  design  and  preventative  maintenance  is  used  to 
protect  mission  reliability.  Although  redundancy  is  required 
to  protect  safety,  the  level  of  redundancy  (dual,  triple,  quad) 
may  be  reduced.  This  however  is  now  and  will  continue  to  be 
an  emotional  issue. 

Hisloncally,  our  aircraft  have  used  two  or  more  radios,  which 
are  in  part,  used  to  communicate  with  different  command 
posts,  air  traffic  control  facilities,  airborne  tankers,  etc.:  but, 
arc  also  trsed  to  ensure  mission  reliability  in  event  one  of  the 
units  fail.  Many  of  our  aircraft  contain  triple  redundant 
menial  navigation  systems,  whose  sole  purpose  is 
accommodate  the  failure  of  one  or  more  of  the  systems.  The 
International  Civil  Aviation  Organization  (ICAO)  mandates 
mple  redundant  navigation  systems  for  operation  in  the  trans- 
AUantic  track  system. 

Conflicts  occur  when  advocates  of  the  AVIP  process  suggest 
that  mission  reliability  can  be  protected  by  preventative 
maintenance  and  robust  design  rather  than  redundancy  While 
there  is  still  a  great  deal  of  disbehef,  these  concepts  will 
become  more  and  more  acceptable  as  program  successes 
become  visible,  as  well  as  continuing  pressures  to  reduce  the 
size  and  weight  of  oar  avionic  systems. 

Redundancy  can  protect  mission  reliability  and  safety  from 
random  failure  events,  but  it  can  not  protect  from  fatigue 
failure  mechanisms.  ASD  recently  procured  a  triple  redundant 
digital  flight  control  system  for  one  of  our  aircraft.  Each  of 
the  triple  redundant  computers  were  installed  in  a  single 
enclosure,  and  thus  would  experience  the  similar  stresses  and 
stress  reversals  over  its  life.  Each  of  the  computers  contained 
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System  Program  Office  Organization  (Typical) 
Figure  6 


a  transistor  lead  wire  that  was  fangue  sensitive.  Thus,  when 
one  fangue  failure  occurs,  the  other  two  computers  are  likely 
to  fail  shortly  thercufter.  Fortunately,  in  this  instance,  the 
fangue  sensinve  part  was  located  in  a  built  m  test  circuit  and 
thus  had  minimal  effect  on  safety.  However,  if  this  design 
error  had  occurred,  and  had  not  been  discovered  before  the 
Stan  of  flight  test,  it  could  have  easily  resulted  in  the  loss  of  all 
three  computers  dunng  a  single  flight  with  die  loss  of  the 
aL'craft  and  die  possible  loss  of  the  aircrew. 

Whose  Responsible?  Reliability  Engineer  or  Designer? 

The  adoption  of  the  AVIP  approach  to  design  requires 
significant  changes  in  the  roles  of  the  electronic  design,  R&M, 
manufactunng  and  test  engineers.  The  organiz.ational 
structure  also  requires  change  to  ensure  the  process  is 
effectively  implemented.  Figure  6  illustrates  the  typical 


System  Program  Office  (SPO)  organizauc  ,al  structure  that 
has  been  in  place  at  ASD  for  the  last  twenty  years  or  so. 

The  engineering  structure  within  the  SPO  has  usually 
organized  as  shown  in  Figure  7. 

With  this  structure,  the  avionic  engineers  have  direct 
responsibility  for  functional  performance  from  the  outset,  but 
they  have  not  been  responsible  for  R&M,  manufacturing  nor 
test.  Responsibility  for  these  disciplines  rests  with  other 
organizations  which  are  “down  the  hail.”  For  example,  if  a 
difference  of  opinion  should  arise  between  the  avionics 
engineer  and  the  R&M  engineer,  that  problem  would  nse  in 
the  line  organization  to  the  Director  of  Engineering,  the 
individual  with  the  total  engineering  responsibility  for  a  major 
weapon  system,  before  resolution  could  be  achieved.  Such  an 
organizational  structure  tends  to  suppress  all  but  the  largest 
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problems.  However,  as  the  development  proceeds,  and  test 
begin,  the  aviomc  engineers  inherit  the  problems.  They  have 
to  deal  with  the  changes  necessary  to  resolve  "iltty"  problems. 
By  in  large,  the  industry  has  mirrored  the  governments 
organizational  structure  in  order  to  streamline  their  customer 
communications 

With  the  implementation  of  AVIP,  the  avionics  engineer 
within  the  SPO  and  the  design  engineer  in  industry  has  been 
asked  to  take  on  the  responsibility  for  the  total  design, 
including  life  charactensdcs,  manufactunng,  etc.  This 
involves  tearing  down  some  organizational,  technical, 
educational  and  cultural  bamers. 

When  the  design  engineer  steps  up  to  his  new  responsibilioes, 
he  will  involve  himself  in  issues  that  have  been  the  private 
domain  of  other  organizations  and  their  specialists  When  he 
does  this,  he  will  encounter  friction  resulting  from  the 
specialists  perceived  loss  of  status,  the  necessity  to  leam  new 
technical  disciplines,  and  ultimately  to  deal  with  the  threat  to 
the  specialists  function.  Further,  the  R&M,  manufacturing 
engineers,  etc  speak  different  technical  languages,  which  will 
requue  a  concerted  effort  from  each  engineer  to  overcome. 
Often,  the  specialists  will  feel  that  the  avionics/design 
engineers  are  unprepared  to  deal  with  their  new 
tesponsibiliues,  they  don't  have  the  experience,  the  education, 
etc  .  It  will  be  said;  “They  simply  don’t  understand.” 

There  will  be  feelings  of  inadequacy  and  distrust  from  the 
avionics  engineers  and  specialists  as  well.  In  order  to 
overcome  these  difficulties,  it  will  require  pauence,  sensitivity 
to  feelings,  effective  training  and  a  lot  of  encouragemer' 
Possibly  the  most  difficult  part  of  the  transformauon  is  making 
the  change  while  applying  the  process  under  schedule  and  cost 
pressures.  It  should  be  recognized  b  >.  .  rssinnot 
something  that  will  occur  over  night  or  on  a  single  program.  It 
will  evolve  with  a  change  in  focus  and  a  commitment  to  make 
it  work  through  incremental  changes.  Organizational  changes 
will  occur  naturally. 

MIL-Spec  Ifesign  Criteria  Verses  Manufacturer  Unique 
Criteria 

MIL-STD-454,  Standard  General  Requuements  for  Electronic 
Equipment,  and  MIL-E-5400,Electronic  Equipment, 
Aerospace,  General  Requirements  for  contain  a  series  of 
detailed  requirements  dealing  with  materials  and  processes 
that  are  acceptable  for  use  in  the  manufaemrer  of  military 
electronics.  Both  of  these  documents  reference  a  mynad  of 
addiuonal  specifications  and  standards  which  reference  more 
requirements,  which  reference  more  requirements,  ad 
nauseam.  As  one  proceeds  through  the  specificauon  tree,  the 
number  and  level  of  detailed  requirements  grow  into  a  totally 
unmanageable  situauon.  As  a  result,  it  has  been  mandated  that 
the  individual  preparing  the  specification  is  required  to 
identify  only  the  specific  requirements  that  apply  to  a 
particular  development.  Often  the  contractor  is  instructed  to 
use  the  remainder  of  the  doruments  as  a  guide,  although  this  is 
of  little  con.sequence  from  a  contractual  standpoint. 

Most  of  our  contracts  also  contain  a  task  to  derate  the 
electronic  parts  that  are  included  in  our  electronic  equipment 
such  that  they  operate  well  below  their  maximum  rated  limits, 
presumably  to  ensure  that  leliabdity  requirements  are 
achieved.  Criteria  for  derating  have  been  documented  in 
AFSC  Pamphlet  800-27,  BtJiabiliiy.f  afls  Derating  Guidelines, 
dated  June  1982  or  USAF  activities  and  NAVMAT  AS-46i3, 
Naval  Air  Systems  Command,  Department  of  the  Navy 
Application  and  Derating  Requirements  for  Electronic 


Components,  General  Specificauon  For  for  USN  applications 
The.se  criteria  focus  primarily  on  the  limitation  of  the  junction 
temperatures  of  semiconductor  devices  and  power  dissipation 
of  other  devices.  The  criteria  was  established  using  industry 
input,  and  ta  tes  into  account  what  some  of  the  mote 
successful  design  teams  have  implemented.  Often,  these 
entena  have  been  mandated  by  contract. 

With  the  application  of  AVIP,  the  contractors  arc  being 
relieved  from  many  of  the  traditional  government  mandated 
material  and  process  requirements  which  the  industry  has 
complained  about  for  years.  It  is  expected  that  the  industry 
will  step  up  to  their  responsibilities,  use  the  knowledge 
developed  throughout  the  development  process,  and  produce  a 
product  that  fulfills  the  users  expectations  without  this  sort  of 
government  “help”.  He  is  expected  to  use  the  government 
specifications  and  standards,  industry  standards,  the  technical 
literature  in  order  to  estabhsh  standards  that  will  be  effective 
in  his  manufactunng  plant  using  his  processes  and  people. 
Obviously,  this  will  require  rising  above  past  adveisanal 
relationships,  dealing  with  each  other  famly,  avoiding  taking 
advantage  of  short  term  personal  gains  and  developing  long 
term  trusting  relationship  between  the  customer  and  the 
supplier. 

MTBF  Verses  Maintenance  Free  Operating  Period  and 
Cumulative  Maintenance  Burden 

Since  the  publication  of  the  AGREE  Report,  MTBF  has  been 
the  accepted  approach  for  stating  reliability  requuements  for 
avionic  equipment.  From  a  standardization  standpoint,  with 
he  concept  that  one  black  box  meets  all  needs,  the  notion  of  a 
single  reliability  number  is  quite  attractive.  However,  this 
leaves  the  practitioner  in  a  quandary  of  relating  the  required 
and  demonstrated  reliability  to  the  reliability  that  will  be 
achieved  in  the  field.  Each  of  us  have  recognized  there  is  no 
single  reliability  number  that  will  apply  universally  to  all 
applications.  The  avionic  equipment  invariably  manifests 
different  rebabdities  in  each  aircraft  model  (i.e.  C-130),  and 
often  with  different  senes  (AC-130H)  within  the  basic  model 
series.  Sometimes  reliability  vanes  with  different  operaung 
bases  and  possibly  different  aircraft  within  the  fleet  Over  the 
years,  the  logistics  community  has  come  to  live  with  the 
situation,  and  has  developed  a  management  planning  process 
(Logistic  Support  Analysis)^  using  the  predicted  MTBFs  and 
fudge  factors  to  deal  with  the  provisioning  of  tlie  equipment 
and  establishing  the  manpower  and  training  requuements  to 
ensure  support. 

With  the  application  of  AVIP,  we  are  now  offering  to  the  user, 
equipment  with  reliability  defined  by  a  different  metric — 
minimum  life,  time  to  first  maintence  event  or  Maintenance 
Free  Operating  Period  (MFOP)  with  a  specified  set  of 
environments  and  usage.  This  recognizes  that  the  equipment 
will  have  different  life  clidracteristics  in  each  application,  and 
that  one  can  adjust  those  life  expectations  based  upon  the 
stresses  the  unit  encounters  m  service.  It  has  been  the 
suggested  that  one  might  want  to  record  the  stresses  during 
equipment  operation  so  that  one  can  perform  preventative 
maintenance  before  it  fails  thus  precluding  it  failing  on  the 
vehicle.  Based  upon  past  experience  with  the  use  of  elapsed 
time  indicators  and  the  use  of  manual  data  collection 
techniques,  there  is  a  mind  set  that  suggests  that  tracking  these 
stresses  can  be  a  very  difficult,  if  not  an  impossible  task.  It 
will  involve  a  large  expenditures  in  manpower.  Fortunately, 
the  technology  available  today  can  be  used  to  mechanize  this 
data  collection  effort. 

There  is  also  a  conflict  with  the  conventional  wisdom  that;  “If 
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it  ain’t  broke,  don’t  fix  it!”  There  is  some  justification  for  this 
position  since  the  repair  process  have  been  mandated  rather 
than  developed  and  veri  M  as  a  part  of  the  development 
process.  Assuming  th  ,epair  processes  ate  characterized  and 
well  understood  (the  same  as  manufacturing  process),  this 
situation  can  be  alleviated. 


Appendix  A 

MIL-STD-78S  Development  Tasks 

MIL-STD-78S  delineates  a  senes  of  activities  or  tasks  that  are 
to  be  accomphshed  dunng  a  development  program 


There  is  a  need  for  a  tailoring  of  the  LS  A  process  or  possibly  a 
translation  from  the  AVIP  metncs  to  a  MTBF.  This 
translation  could  be  used  for  solving  queing  problems  inherent 
to  the  LSA  process. 

Contract  for  Warranties  Verses  AVIP  Plus  Warranties 

There  ate  those  who  suggest  that  one  need  not  require  and 
monitor  a  development  process  since  warranties  protect  the 
governments  interests.  There  are  fundamental  problems  with 
an  approach  that  does  not  allow  the  customer  the  opportunity 
to  intercede  if  necessary.  The  customer  can  not  afford  to  have 
a  program  proceed  on  a  course  that  will  result  in  failure 
without  visibility  in  its  progress,  only  to  discover  that  the 
hardware  is  poorly  designed  when  tests  begin.  Thus  the 
process  is  necessary  from  a  both  a  technical  and  management 
standpoint,  warranties  are  optional. 

This  is  not  to  say  that  warranties  have  not  had  value.  They 
have  often  been  marketed  as  Reliability  Improvement 
Warranties,  although  they  have  fundamentally  been  priced  as 
intenm  support  contracts  with  punitive  actions  resulting  if 
reliability  or  turn  around  cotrmutments  are  not  met.  Fu^er, 
they  address  only  the  cost  of  repair  which  is  a  small  portion  of 
the  total  cost  of  a  failure.  The  cost  of  a  failure  mcludes  the 
opportunity  costs  resulting  from  the  loss  in  availability  of  the 
aircraft,  the  lost  mission,  failure  to  meet  training  objectives, 
the  manpower  to  verify  a  failure,  remove  and  replace  the  unit, 
pack  and  ship  tlie  unit  to  the  factory  for  repair,  return  shipping, 
and  the  investment  cost  of  the  unit  while  it  is  not  available  for 
use.  There  is  no  substitute  for  the  application  of  a  disciplined 
systems  engineering  process. 

Conclusion: 

The  implementation  of  the  Avionics  Integrity  Program  is  an 
idea  who's  time  has  come.  It  is  time  to  move  from  the 
traditional  approach  of  R&M  to  a  more  disciplined 
development  process.  The  avionics  will  exhibit  more 
predictable  life  characteristics,  based  upon  the  operational 
usage  and  environmental  stresses  encountered.  The  process 
provides  the  capability  to  adjust  life  expectations  as  the 
equipment  is  used  differently,  used  on  different  platforms,  or 
different  locations  with  different  environments  on  similar 
platforms.  This  will  al' jw  l  e  application  of  preventative, 
opportunistic  or  coriei  tive  ’  laintenance  policies  based  upon 
the  consequence  of  failure  and  economic  considerations.  The 
process  can  be  applied  for  both  large  and  small  production 
runs. 

Thus,  the  application  of  AVIP  takes  advantage  of  the 
economies  of  scale  and  the  application  of  preventative  and 
corrective  maintenance  support  options  to  achieve  the 
maximum  war  fighting  capability  for  the  minimum 
expenditure  of  assets.  Thus,  AVIP  supports  the 
standardization  objectives,  and  maximizes  our  users  war 
fighting  capability 


MIL-STD-78S  Development  Tasks 
Reliability  Program  Plan 

Monitor/Control  of  Subcontractors  and  Suppliers  Program 
Reviews 

Failure  Reporting,  Analysis,  and  Corrective  Action  System 
(FRACAS) 

Failure  Review  Board 
Reliability  Modeling 
Rchability  Allocations 
Reliability  Predictions 

Failure  Modes,  Effects  and  Cntically  Analysis  (FMECA) 
Sneak  Circuit  Analysis  (SCA) 

Electronic  Patts/Circuits  Tolerance  Analysis 
Parts  Program 
Reliability  Critical  Items 

Effects  of  Functional  Testing,  Storage,  Handling,  Packaging, 
Transportation,  and  Maintenance 
Envuonmental  Stress  Screen  (ESS) 

Reliability  Development/Growth  Test  (RDGT)  Program 
Reliability  Qualification  Test  (RQT)  Program 
Production  Reliability  Acceptance  Test  (PRAT)  Program 

Unfortunately,  only  limited  guidance  is  provided  on  how  the 
tasks  are  to  be  time  phased,  and  this  guidance  is  contained  in 
MIL-STD-1521,  Technical  Reviews  and  Audits  for  Systems. 
Equipments,  and  Computer  Software,  which  defines  the 
requirements  for  the  various  program  reviews.  Witliin  the 
broad  guidance  provided,  the  time  phasing  of  the  effort  is  left 
to  the  discretion  of  the  reliability  engineer  to  define  with  the 
concurrence  of  program  management.  Since  the  MIL-STD 
defines  tasks  rather  than  a  process,  the  discipline  that  is 
applied  to  the  development  often  becomes  a  test  of  the 
personalities  of  the  reliability  engineers  and  program 
managers  (both  within  industry  and  the  customer 
organizations).  When  a  development  effort  encounters  trouble 
from  either  a  cost  or  schedule  standpoint,  the  Reliability 
Program  mote  often  than  not  is  reduced  in  scope  and/or 
delayed. 

The  planning  and  results  of  the  MIL-STD-785  tasks  are 
documented  in  accordance  with  the  Data  Item  Descriptions 
listed  below. 

DI-R-7079 
Dl-R-7080 
DI-R-7041 

Dl-R-7081 

Dl-R-2114 
DI-R-7082 
DI-R-1734 

DI-R-2115A 

Dl-R-7083 


Reliability  Program  Plan 
Reliability  Status  Report 
Report,  Failure  Summary  and 
Analysis 

Reliability  Mathematical 
Model(s) 

Report,  Reliability  Allocation 
Reliability  Predictions  Report 
Report,  Failuie  Modes,  Effects 
and  Criticality 

Repon,  Failure  Mode  and  Effect 
Analysis  (FMEA) 

Sneak  Circuit  Analysis  Report 
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DI-R-7084 

D1-R-3501 1 
Dl-R-7040 
DI-R-7033 
DI-R-7034 

DI-R-7034 


Electronic  Parts/Circuits 
Tolerance  Analysis  Repon 
Plan,  Cntical  Item  Control 
Report,  Bum-in  Test 
Plan,  Reliability  Test 
Procedures,  Reliability  Test  and 
Demonstration 
Reports,  Reliability  Test  and 
Demonstration  (Final  Report) 


It  is  certainly  fair  to  attribute  some  of  the  improved  field 
reliability  that  has  been  observed  over  the  past  twenty  years  to 
the  diligent  application  of  the  MIL-STD-785  tasks  by  the 
R&M  engineers.  However,  it  should  be  recognized  that  there 
are  many  other  factors  that  have  also  contributed.  These 
Include  the  revolution  that  the  electronics  industry  has 
undergone  which  include  the  engineering  design  tools, 
automation  of  the  manufacturing  processes  and  the 
components  that  are  used  in  our  electronic  equipments. 

Avionic  systems  have  evolved  from  vacuum  tube  based 
systems,  to  those  using  discrete  semiconductors  devices,  and 
later  to  small  and  medium  scale  integrated  circuits.  At  this 
time,  new  systems  are  made  predominantly  of  medium  to  large 
scale  integrated  circuits  and  are  moving  toward  Very  High 
Speed  Integrated  Circuit  (VHSIC)  devices.  It  is  certainly 
reasonable  to  attnbute  a  large  portion  of  the  improvement  to 
the  use  of  current  technology  components,  computer  aided 
design  and  automation  of  the  assembly  and  test  processes 
rather  than  the  application  of  MIL-S'IT)-785.  At  this  point,  it 
would  be  instructive  to  discuss  several  of  the  specific  tasks 
required  by  MIL-STD-785. 


handbook  only  provides  failure  rate  prediction  models  which 
account  for  manufacturing  (e.g.,  wire  bond,  package  related, 
etc),  temperature,  electrical  stress  and  other  quality/application 
considerations  which  collected  field  data  indicates  to  be 
significant  problem  areas  in  fielded  electronics.  These  factors 
are  generally  generic  to  systems,  manufacturers  a-d  field 
maintenance  policies.  One  should  realize  that  field  reliability 
IS  the  only  reliability  that  is  of  importance  to  our  users  and 
maintainers  and  should  be  a  prime  concern  of  the  equipment 
designer. 

Mr.  Morris  listed  tlie  purposes  for  accomplishing  the 
reliability  prediction  as:  (1)  feasibility  evaluation,  (2) 
comparing  competing  designs,  (3)  identification  of  potential 
reliability  problems  and  (4)  to  provide  reliability  input  to  other 
R/M  tasks.  Mr.  Morris  goes  on  to  suggest  that  the  lack  of  an 
accurate  prediction  of  field  reliability  does  not  diminish  the 
value  of  the  handbook  or  prediction  process  since  none  of  the 
purposes  described  above  require  an  absolute  prediction  of 
field  reliability.  Unfortunately,  it  is  not  apparent  that  the 
inaccuracies  of  the  MIL-HDBK-217  prediction  varies  widely 
from  manufacturer  to  manufacturer,  and  betsveen  design  teams 
and  specific  plants  within  a  particular  manufacturer. 

It  should  be  apparent  that,  if  the  data  used  in  making  system 
level  design  trade  decisions  is  as  unrepresentative  of  what  will 
be  experienced  in  the  field  as  Mr,  Moms  acknowledges,  and 
that  the  field  reliability  varies  widely,  the  design  trade 
decisions  are  themselves  questionable.  The  outcomes  of  any 
further  analyses  based  upon  inputs  derived  from  MIL-HDBK- 
217  are  suspect. 


Reliability  Predictions: 


Parts  Program 


While  the  Reliability  Prediction  Task  is  only  one  of  several 
tasks  requued  of  a  Reliability  Program,  it  is  one  of  the  two 
efforts  which  are  key  (the  second  being  the  Pans  Program)  in 
accomplishing  the  detailed  design.  MIL-STD-785  directs  the 
reliability  engineer  to  MIL-HDBK-217.  Reliability  Prediction 
of  Electronic  Kquinmeni.  for  appropriate  failure  prediction 
techniques.  MIL'HDBK-217  stated  purpose  is:  establishes 
uniform  methods  for  predicting  the  reliability  of  military 
electronic  equipment  and  systems.  It  provides  a  common 
basis  for  reliability  predictions  during  acquisition  programs  for 
military  electronic  systems  and  equipment  It  also  establishes 
a  common  basis  for  comparing  and  evaluating  reliability 
predictions  of  related  or  competitive  designs.  However,  its 
application  and  usefulness  have  rather  controversial  in  recent 
times. 

The  Reliability  Analysis  Center  (RAC),  a  DOD  Analysis 
Center,  has  published  in  their  Apnl  1990  Technical  Brief  a 
defense  of  MIL-HDBK-217  titled,  MIL-HDBK-217.  Use  and 
Application  by  Mr  Seymour  F  Morris,  RADC/RBER.  Mr 
Moms  observed  that.  Critics  often  state  that  reliability 
predictions  using  MIL-HDBK-217  do  not  compare  well  to 
field  expenence  and  the  results  obtained  are  too  often 
misunderstood  and  misused  Some  engineers  see  the  whole 
prediction  process,  and  MIL-HDBK-217  in  particular,  as  an 
impediment  to  good  engineering  judgement  and  cali  for  its 
elimination.  Mr.  Morris  later  coirectly  states  that  MIL- 
HDBK-217  is  not  intended  to  predict  field  reliability  and,  in 
general,  does  not  do  a  very  good  job  at  it  in  an  absolute  sense. 
The  reasons  for  this  are  numerous  including  different  failure 
definitions  for  field  problems  that  MU  -HDBK-217  does  not 
account  for.  These  problems  include  maintenance  induced 
failures,  intermittent  failures  (can  not  duplicate),  software 
problems,  and  design  problems  (i.e.,  overstressed  parts 
operating  beyond  their  ratings).  He  funlier  stated  that  The 


The  AGREE  Committee  (1957)  recommended  that:  the 
development  of  military  component  specifications,  the  testing 
of  components  for  design  capability,  and  die  development  of 
inspection  methods,  be  integrated  and  coordinated  by  one 
coordinating  group  at  D.O  D.  level.  The  group  should  be 
comprised  of  representatives  from  industry  and  from  the  three 
Services,  including  personnel  from  Research  and 
Development,  Standardization,  Procurement,  and  Quality 
Assurance  functions.  This  recommendation  was  implemented 
with  the  issuance  of  DoD  412Q.3-M.  Defense  Standardization 


and  Specifitration  Program  Policies.  Procedures  and 
Instniciion.s'  which  were  issued  in  January  1972  and  revised 
in  August  1978  and  the  establishment  ofMlL-STD-965.  Parts 
Control  Program.  MlL-STD-965  invoked  a  single 
standardized  process  on  each  of  the  three  services  and  their 
contractors  The  implementation  of  the  process  is  documented 
by  Data  Item  Descriptions  below. 


DI-E-7026 

Dl-E-7027 

DI-E-7028 


DI-E-7030 
DIE- 1 133 

DI-E-703I 


Parts  Control  Program  Plan 
Program  Parts  Selection  List 
Nonstandard  Parts  Approval 
Requests/Proposed  Additions  to  an 
Approved  PPSL  DI-E-7029  Militaiy 
Detail  Specifications  and 
Specification  Sheets 
Test  Data  for  Nonstandards 
Specification  Requirements  Sheets 
(SRS) 

Drawings,  Engineering  and  Associated 
Lists 


The  implementation  of  parts  standardization  effort  has  been 
delegated  to  the  Defense  Logistics  Agency  (DLA)  by  the 
Department  of  Defense.  The  DLA  activity  responsible  for 
electronic  parts  is  the  Defense  Electronics  Supply  Center 
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(DESC).  DESC  IS  the  custodian  for  the  militaiy  specifications 
that  relate  to  electronic  parts.  For  microcircuits,  Rome  Air 
Development  Center  (RADC)  is  the  preparing  activity  for  both 
general  and  detail  militaiy  specifications  and  has 
responsibihty  for  their  content.  They  also  have  the  technical 
capability  and  laboratory  facilities  to  suppon  the  effort. 

Changes  to  the  general  electronic  part  specifications  may  be 
proposed  by  government  or  industry  representatives,  and  are 
coordinated  with  the  Electronic  Industries  Association  (EIA). 
Generally  the  EIA  will  work  toward  achieving  a  consensus 
within  the  industry  before  recommending  incorporation, 
although  individual  companies  may  sponsor  proposed  changes 
for  which  consensus  has  not  and  can  not  be  reached.  RADC 
may  iiismict  DESC  to  publish  positions  developed  through 
industry  consensus,  recommended  by  individual  companies,  or 
positions  opposed  by  industry. 

DESC  coordinates  new  and  changes  to  existing  Associated 
Detail  Specifications  (slash  sheets)  and  Standarrlized  Military 
Drawings  (SMDs),  for  which  DLA  is  the  preparing  activity 
with  appropriate  vendors.  These  documents  define  the 
electronic  function,  performance,  form  factor,  qualification 
and  screening  and  inspection/lest  requirements  for  specific 
electronic  parts. 

In  order  to  maintain  multiple  sources  and  competition,  the 
slash  sheets  and  SMDs  are  often  silent  on  key  parameters 
(e.g.,  timing  parameters,  output  current  sink/source  capability, 
etc.)  where  one  or  more  of  the  producers  are  unable  or 
unwilling  to  comply.  These  omissions  often  results  fiom 
limitations  of  existing  facilities,  processes  or  process/test 
equipment,  yield,  or  unieconcilable  differences  in  key 
parameters  from  one  vendor  to  another.  In  order  to 
accomplish  the  design,  data  from  similar  commercial  pans  or 
CAD/simulation  models  which  are  far  more  detailed  are  often 
used.  Unfortunately,  the  manufacturing  controls  and  quality 
conformance  inspections  and  screens  apphed  to  the  military 
product  may  be  less  stringent  than  the  commercial  or 
industrial  high-rel  counlerpan.  Products  that  ate  particularly 
susceptible  to  these  problems  are  bought  to  Qualified  Products 
Lists  (QPL)  that  were  established  years  earlier.  Reliability  is 
not  addressed  by  the  microcircuit  QPL  processg.  The 
Qualified  Manufacturers  List  (QML)  process  has  recently 
been  implemented  and  is  expected  to  alleviate  many  of  the 
above  problems  on  new  Application  Specific  Integrated 
Circuits  (ASIC). 

Upon  receipt  of  a  new  contract,  the  contractor  is  provided  with 
a  DESC  prepared  Government  Furnished  Baseline  (GFB).  The 
GFB  includes  those  parts  which  DESC,  based  upon  their 
experience,  believes  are  appropriate  for  use  in  the  new 
development  system.  The  contractor  then  takes  the  GFB, 
deletes  those  parts  that  are  not  to  be  used,  adds  new  parts  as 
necessary  to  complete  the  design,  and  submits  this  list  to  the 
government  for  approval  as  the  Preferred  Parts  Selection  List 
(PPSL) 

After  the  approval  of  the  PPSL  (which  occurs  long  before  the 
design  is  complete),  the  contractor  is  required  to  submit 
requests  approval  for  the  addition  of  either  a  standard  or 
nonstandard  part.  For  each  nonstandard  part,  a  “Nonstandard 
Pans  Approval  Request/Proposed  Additions  to  an  Approved 
PPSL"  form  is  submitted  to  DESC.  DESC  does  a  pan  number 
Cross  reference  check  to  determine  if  there  is  an  existing  pan 
from  a  QPL  or  SMD  approved  source  that  performs  the  same 
function,  although  not  necessarily  the  same  electrical 
performance  or  reliability.  An  approved  source  may  be 


established  as  a  result  of  government  certificaaon/qualification 
(QPL)  or  company  self  certification  (SMD)  procedure.  If  a 
functionally  similar  pan  is  found,  DESC  recommends  that  it 
be  used. 

Although,  the  documentation  requires  technical  justification, 
that  information  is  seldom  considered  in  the  approval/ 
disapproval  recommendation.  From  a  practical  standpoint,  the 
DESC  recommendation  is  final  unless  the  contractor  make.*:  a 
formal  appeal  to  the  procunng  agency  for  reconsideration. 

The  procuring  agency  can  over  ride  DESC’s  recommendation 
for  any  number  of  reasons,  but  they  are  compelled  by 
regulation  to  notify  DESC  of  the  reasons  for  over  nde.  While 
there  are  ways  of  speeding  up  the  procedure  through  the  use  of 
a  Pans  Control  Board,  the  bureaucratic  drill  is  time  consuming 
and  documentation  intensive. 

Environmental  Stress  S'ereen 

Subsequent  to  the  release  of  the  AGREE  Report,  some  of  our 
specifications  required  that  bum-in  be  accomplish  on  each 
delivered  equipment,  and  it  was  instituted  on  other  contracts  as 
corrective  action  when  necessary  reliability  was  not  achieved. 
The  inertial  navigation  system  for  the  F- IS  aircraft  (circa  early 
1970s)  required  that  a  bum-in  (operation  at  elevated 
temperature)  test  be  completed  prior  to  delivery,  but  would 
either  arrive  at  the  aircraft  manufacturers  plant  “dead  on 
arrival”  or  would  fail  soon  there  after.  The  INS  was  an 
intergral  pan  of  the  avionics  suite  of  the  F-15,  and  its 
unreliability  was  delaymg  the  aircraft  delivery,  which  was 
unacceptable  for  both  the  prime  contractor  and  the  customer. 

The  Air  Force  had  considerable  experience  with  silo  based 
missile  systems  hat  contained  older  technology  inertial 
platforms  which  operated  continuously  for  months  without 
failure.  The  airlmes  were  reporting  reliabilities  on  the  order  of 
2000  hours  MTBF  on  their  inertial  systems  that  they  were 
using  on  many  of  their  transoceanic  flights  and  were  reporting 
reliaWlity  figures  on  the  order  of  2000  hours  MTBF.  Yet,  the 
Air  Force  was  seldom  achieving  twenty  (20)  hours  on  their 
fighter  aircraft. 

Thus,  It  was  suggested  that  power  and  thermal  cycles  may  be 
more  important  reliability  cUver  than  time  at  temperature. 
Although  the  contractor  objected,  a  change  to  the  acceptance 
procedure  was  implemented  which  required  a  series  of  power 
and  thermal  cycles,  including  several  at  the  end  which  were  to 
be  failure  free.  This  test  precipitated  a  numerous  failures 
before  the  equipment  was  delivered,  which  provided  near  real 
time  feedback  on  design  and  manufacturing  problems.  Soon 
the  reliability  problems  at  the  prime  contractor  and  the  field 
diminished. 


During  the  mid  70s,  the  Air  Force  developed  a  new  standard 
UHF  Radio  which  experienced  similar  problems.  The  basic 
requirements  included  a  steady  state  bum-in  prior  to  delivery. 
When  problems  were  encountered,  an  experiment  was  set  up 
where  half  of  the  deliverable  units  would  undergo  steady  state 
bum-in  while  the  others  received  thermal  and  powm  cycling,  a 
portion  being  failure  free.  Before  the  test  approached  it’s 
designated  decision  point,  it  was  apparent  that  thermal  and 
power  cycling  were  more  effective  in  inducing  early  failures 
than  operating  at  elevated  temperature.  Thus,  the  decision  was 
made  to  integrate  Environment  Stress  Screen  (ESS)  in  the  way 
ASD  conducts  bu..iness.  Within  the  vernacular  of  the 
reliability  engineers,  ESS  and  bum-in  have  become 
synonymous. 
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Reliability  Development/Growth  Test  (RDGT)  Program 

The  purpose  of  accomplishing  a  RDGT  is  to  conduct  pie- 
qualificaticn  testing  (also  known  as  Test  Analyze  and  Fix)  to 
identify  reliability  problems  and  make  changes  to  the  design 
or  manufacturing  processes  prior  to  production  release.  The 
test  should  weed  out  failure  mechanisms  that  were 
unintennonally  allowed  in  the  design.  Test,  analyze  and  fix  is 
useful  when  applied  at  the  appropriate  time  in  concert  with  a 
disciplined  development  process.  Unfonunately,  the 
implementation  of  RDGT  has  encountered  numerous 
difficulties.  Some  contractors  have  opted  to  find  and  tlx  the 
problems  in  RDGT  rather  than  accomplish  simple  analyses 
prior  to  drawing  release,  when  the  available  design  options 
become  more  limited.  The  implementation  of  RDGT  has 
encourage  an  abbreviation  of  the  design  process  by  requiring 
the  application  of  a  learning  curve  to  reliability  during  RDGT 
as  well  as  a  mature  reliability.  To  meet  the  learning  curve 
requued  without  exceeding  the  mature  reliability  requirement, 
the  equipment  must  begin  RDGT  with  an  abysmally  low 
reliability. 

Another  problem  with  the  irnplementauon  of  RDGT  is  that  of 
schedule.  At  the  outset,  the  schedule  includes  time  for 
completion  of  RDGT  and  changes  incorporated  prior  to  the 
start  of  flight  test  and  reliability  qualification  test. 
Unfortunately,  all  too  often  the  design  encounters  problems, 
cost  and  schedule  pnonties  prevail  and  the  start  of  RDGT  is 
delayed.  This  combined  with  the  short  cut  design  process 
results  in  immature  equipment  being  pressed  into  flight  test, 
often  placing  the  program  itself  in  jeopardy. 


On  the  C-141  program,  the  RQT  was  conducted  with 
prototype  equipments  which  are  much  more  costly  than 
similar  units  built  in  production.  As  the  MTBFs  of  the  test 
hardware  grew,  the  number  of  test  articles  required  to 
demonstrate  the  required  MTBF  within  the  available  time  also 
increased.  Further,  it  was  recognized  that  the  pre-production 
or  prototype  equipments  were  not  representative  of  production 
hardware.  In  order  to  minimize  the  cost  of  the  test,  and  use  test 
samples  that  are  representative  of  production  hardware,  the 
RQT  wac  delayed  until  after  the  start  of  production. 
Unfortunately,  the  possibility  impacting  the  design  with 
knowledge  obtained  from  the  RfJT  before  production  release 
was  lost. 

Worse  still  were  the  demotivating  effects  of  the  delay.  After 
production  begins,  the  contractor  is  often  responsible  for 
incorporating  changes  in  delivered  units  to  achieve  the 
required  M  TBF.  This  obliganon  caused  the  contractor  to 
resist  change  where  ever  possible.  This  precluded  the 
incorporation  of  improvements  in  production  hardware  as 
well.  While  the  maintainers  want  mere  reliable  equipment, 
they  resist  programed  retrofits  that  increase  their  immediate 
work  load.  Once  production  has  been  begunO,  the  acquisition 
community  is  most  interested  in  completing  production  and 
transferring  responsibility  to  the  supporting  agency.  Thus 
there  were  an  overwhelming  set  of  forces  that  inhibit 
improvement  of  field  reliability. 


Appendix  B 


Reliability  Qualification  Test  Program 

The  AGREE  Comrmttee  recommended  a  statistically  based 
test  which  could  be  used  to  demonstrate  that  a  minimum 
MTBF  had  been  achieved.  They  identified  specific 
environmental  limits  for  temperature,  vibration,  on-off  cycling 
and  input  voltages  for  each  of  four  different  test  levels.  These 
test  levels  were  designated  light,  medium,  high  and  extreme 
conditions  and  included  a  rather  straight  forward  accept/reject 
criteria. 

The  basic  requirements  for  AGREE  Tesung  were  first  applied 
to  the  development  of  the  C-141  Aircraft.  The  Reliability 
Qualification  Test  was  accomplished  on  pre-production 
hardware  and  was  in  most  cases  complete  before  the  start  of 
production.  This  program  applied  a  single  test  plan  (failures 
verses  operating  hours)  and  an  accept/rejeci  critena  that  was 
adjusted  based  upon  the  required  MTBF  to  each  avionic 
equipment. 

When  the  AGREE  Report  was  wntten,  the  implementation  of 
a  Reliability  Qualification  Test  (RQT)  was  practical  from  a 
time  standpoint.  The  MTBFs  for  most  avionic  equipments 
were  less  than  100  hours  and  the  troublesome  units  were  often 
less  than  ten  (10)  hours.  With  MTBFs  of  these  magnitudes,  a 
RQT  could  be  accomplished  with  each  test  sample 
accumulating  multiple  MTBFs  within  an  acceptable  calendar 
time  period.  As  the  industry  moved  to  more  modem 
technologies,  increased  automanon  and  better  pnxiess  control, 
the  achievable  MTBFs  have  increased  greatly.  Thus,  it  has 
become  impractical  and  often  impossible,  to  accomplish  a 
RQT  with  an  reasonable  number  of  test  assets,  test  hours  and 
cost  or  within  a  reasonable  calendar  lime. 


This  matenal  was  extracted  from  a  technical  paper  titled 
“Tools  Available  for  Implementing  AVIP”  by  Mr,  Dave  S. 
Steinberg  of  Litton  Guidance  &  Control  Systems  and  was 
published  in  the  Proceedings  of  the  Ninth  Annual  IEEE/ 
AESS,  Dayton  Chapter  Symposium,  “Avionics  Integrity 
Program”  held  in  Dayton,  Ohio,  30  November  1988. 


INTRODUCTION 


The  approximate  fatigue  life  of  an  electronic  system  can  be 
determined  from  the  fatigue  characteristics  of  the  various 
members  that  cany  major  structural  loads.  The  fatigue 
characteristics  are  typically  plotted  on  log-log  paper  and 
presented  in  terms  of  stress  (S)  and  number  of  cycles  to  fail 
(N).  These  S-N  curves  are  shown  as  straight  sloped  lines, 
using  the  best  average  values,  as  shown  in  Fig.  I.  [  1 1 


=  N2S2'’ 


Test  data 
scatter 


Typical  S-N  FaUgue  Curve 
Figure  1 


The  general  equation  for  the  straight  sloped  line  on  the  log- 
log  plot  is:  .  , 

NiSi'’  =  N2S2*’  (1) 


WhereiN  =  Number  of  stress  cycles 
S  =  Stress  level  for  failure,  psi 
b  =  Slope  of  fatigue  line 
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Considering  linear  systems,  the  number  of  fatigue  cycles  will 
be  directly  proportional  to  the  time  (T).  Also,  the  stress  level 
will  be  diiectly  proportional  to  the  acceleration  (G)  level  and 
to  the  displacement  amplitude  (Z).  Therefore,  (1)  can  be 
rewritten  as  follows: 


T,Gi*>  =  T2G2‘> 
NiZib  =  N2Z2>> 
NiGi'>  =  N2G2'’ 


(2) 


The  above  equations  can  be  used  to  determine  the  fatigue  life 
of  various  structural  load  carrying  members  subjected  to 
different  alternating  stresses  in  different  environments. 


FATIGUE  CHARACTERISTICS  OF  SOLDER 

Solder  has  some  unusual  physical  properties  that  must  be 
understood  in  order  to  design  and  manufacture  reliable 
electronic  equipment.  Since  solder  is  a  relatively  soft  metal, 
with  a  low  melting  temperature,  the  modulus  of  elasticity  and 
shear  strengtii  are  reduced  when  the  operating  temperatures 
are  near  100  C.  Solder  shows  a  tendency  to  plasdcally 
deform  and  creep  under  relanvely  low  stress  levels  of  about 
800  psi  at  these  elevated  temperatures,  during  slow 
temperamre  cycling  conditions. 

The  strength  of  solder  appears  to  increase  as  the  speed  of  the 
applied  load  is  also  increased.  [2]  Solder  can  therefore 
withstand  higher  stress  levels  during  rapidly  applied  loads, 
such  as  vibrauon,  than  during  slowly  applied  loads,  such  as 
thermal  cychng. 

The  typical  farigue  curve  for  63%  tin  37%  lead  solder  in  shear 
is  shown  in  Fig  2,  for  room  temperature  conditions  13] 


N  Cycles  To  Fail 

Shear  Fatigue  Properties  of  Solder 
Figure  2 

Extensive  experience  with  solder  joints  in  military  programs 
has  shown  that  solder  stress  levels  should  be  kept  below  a 
level  of  about  400  psi,  to  avoid  creep  failure  fatigue  effects 
due  to  slow  thermal  cychng  over  long  time  periods. 


suer.gth  is  about  6,000  psi.  At  temperatures  around  100  C, 
where  many  military  components  operate,  the  strength  of  the 
solder  is  sharply  reduced. 

6,000 

Stress  4,000 
PSI 

2,000 


0 

N  -  Cycles  to  Fail 

Solder  Alternating  Lap  Shear  Stress  63-37  Tin  Lead 
Figures 

EFFECTS  OF  THERMAL  EXPANSION  MISMATCH 
BETWEEN  COMPONENTS  AND  PCB 

Thermal  expansion  and  contraction  differences  between  the 
electronic  components  and  the  PCB’s  must  be  kept  to  a 
minimum  in  Older  to  reduce  thermal  strains  and  stresses  in  the 
lead  wires,  solder  joints  and  plated  through  holes.  Materials 
must  be  carefully  selected  to  minimize  expansion  di^erences, 
or  the  mounting  component  geometry  must  be  adjusted  to 
reduce  the  thermal  coefficient  of  expansion  (TCE)  forces 
developed  in  the  lead  wires  and  solder  joints. 

The  solder  workmanship  and  control  is  extremely  critical  for 
surface  mounted  components,  since  there  are  no  other 
mechanical  suppoils  for  the  leadless  ceramic  chip  carriers 
(LCCCs).  When  the  solder  joints  are  not  properly  made  or 
control!^,  then  more  rapid  failures  can  be  expected. 

Plated-through  holes  must  be  sized  properly  to  prevent 
cracking  of  the  copper  plating  in  the  hole.  There  must  be 
enough  copper  in  me  plated-through  hole  to  car^  the  forces 
generated  by  the  expansion  of  the  circuit  board  in  the  Z 
direction  Even  when  the  PCB  expansion  in  the  X  and  Y  (in 
plane)  axes  are  reduce  I  with  the  use  of  materials  such  as 
copper  clad  invar,  the  Z  axis  expansion  (perpendicular  to  the 
plane  of  the  board)  will  not  be  reduced.  Therefore,  the 
laminations  for  multi-layer  PCB’s  must  not  be  made  too  thick 
because  the  Z  axis  expansion  can  become  a  problem  The 
aspect  ratio  for  a  plat^  through  hole  should  be  about  3  for  a 
reliable  design,  [SJwhere  the  thickness  of  the  PCB  is  limited 
to  3  times  the  diameter  of  the  hole. 

The  copper  in  the  plated  through  holes  should  have  a 
minimum  thickness  of  0.0015  inches  to  prevent  cracking  of 
the  copper  barrel  during  temperature  cycling  environments. 

ELECTRONIC  COMPONENT  LEAD  WIRE 
STRAIN  RELIEF 


10*  102  10^  10“*  1()5  10®  10^ 


Higher  stress  levels  are  often  permitted  during  vibration  for 
short  time  periods.  However,  for  extended  periods  of 
vibration  many  millions  of  stress  reversals  can  result  because 
pnnted  circuit  boards  (PCBs)  typically  have  high  resonant 
fiequencies.  Solder  creep  in  vibration  is  not  a  problem  since 
the  stress  reversals  are  very  rapid.  For  exiendM  vibration 
environments  the  400  psi  level  should  be  observed  to  avoid 
fatigue  cracks  in  the  solder  due  to  the  accumulation  of  several 
million  stress  cycles. 

The  fatigue  properties  of  solder  under  cyclic  loads  shows  that 
the  fatigue  strength  is  reduced  when  the  frequency  of  the 
applied  load  is  r^uced.  A  companson  of  the  fatigue  life  for  a 
lo^  frequency  of  5  cycles  per  minute  and  a  load  fiequency  of 
0.06  cycles  per  minute  is  shown  in  Fig.  3  at  a  constant 
temperature  of  25  C.  This  shows  that  for  a  given  number  of 
stress  reversals,  such  as  may  be  experienced  in  a  temperature 
cycling  environment,  a  slow  .emperatuie  cycle  is  more 
dwiaging  than  a  rapid  tempe.ature  cycle  over  the  same 
temperature  range.  [4] 

Temperature  also  has  a  strong  influence  on  the  strength  of 
solder.  At  low  tcmpeiatures  of  -55  C  the  short  time  tensile 


Relative  motion  between  the  electronic  components  and  the 
PCB  can  be  developed  as  the  result  of  a  thermal  expansion 
mismatch  or  as  the  result  of  a  resonant  condition  in 
the  PCB,  During  the  resonani  condition  the  PCB  is  forced  to 
bend  back  and  forth.  This  motion  forces  the  electrical  lead 
wires  to  also  bend  back  and  forth  as  shown  in  Fig.  4. 

Stresses  Developed  in  Electrical  Leads 


Bending  Produces  Strain  in  Lead  Wires 
Figure  4 

The  effects  of  a  large  thermal  expansion  mismatch  or  a  large 
vibration  displacement  mismatch  between  the  components 
and  the  P^  can  often  be  offset  by  reducing  the  stiffness  of 
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the  wires  on  the  electronic  components.  When  the  wire 
stiffness  is  reduced,  the  forces  and  the  stresses  in  the 
wires  and  in  the  solder  joints  are  also  reduced. 

Wires  can  be  looped  or  even  coined  (by  squeezing  a  round 
wire  into  a  thin  flat  strip)  to  reduce  the  stiffness.  The  typical 
spring  rate  relation  can  be  used  to  demonstrate  this  condition. 
For  a  given  thermalmismatch  condition,  or  a  given  resonant 
condiuon,  where  the  relative  displacement  (Y)  is  fixed,  the 
only  way  in  which  the  force  (P)  can  be  reduced  is  to  reduce 
the  spring  rate  (K)  of  the  wire,  as  shown  in  the  following 
relation: 

P  =  KY  (3) 

When  the  spring  rate  of  the  wire  is  due  to  bending,  then  the 
flexing  spnng  rate  (K) 

is  related  to  the  modulus  of  elasticity  (E),  the  area  moment  of 
inenia  (I),  and  the  length  (L)  as  follows; 

El 

K= - ^  (4) 


Looping  the  wires  increases  the  length  (L)  so  the  stiffness  is 
reduced  rapidly  due  to  the  cube  function.  Coining  the  lead 
wires  reduces  the  moment  of  inertia  (I),  which  is  a  cubic 
function  of  the  height,  so  the  stiffness  is  reduced  rapidi; . 
When  the  spring  rate  of  the  wire  is  in  tension,  then  the  area  of 
the  wire  (A)  is  required  as  follows: 

AE 

K=  -  (5) 

L 

A  longer  wire  will  reduce  the  spnng  rate  as  a  linear  relation, 
so  the  spring  rate  changes  slowly. 

ESTIMATING  THE  VIBRATION  FATIGUE  LIFE 


The  approximate  fatigue  life  of  a  vibrating  system  can  often 
be  estimated  from  the  fatigue  properties  of  the  various 
members  that  carry  the  dynattuc  loads.  Since  electronic 
assemblies  make  use  of  non  ferrous  metals  in  components, 
these  charac 
tenstics  will  be  used. 

The  slope  of  the  fatigue  curve  shown  in  Fig.  1  can  be 
determined  by  considering  the  endurance  limit  to  be  one  third 
of  the  ultunate  tensile  strength.  [6]  Then  rewriting  Eq.(l)- 


N2  = 


(6) 


typically  be  mounted  by  its  electrical  lead  wires  only,  without 
any  supporting  screws.  This  type  of  transformer  must  have  at 
least  7  wires  per  inch  of  diameter  to  suppon  the  unit.  When 
only  4  wires  are  required  for  electncal  operation,  then  3 
dummy  wires  must  be  added  to  permit  the  transformer  to 
survive  severe  thermal  and  vibration  environments. 


SAMPLE  PROBLEM  - 
TRANSFORMER  MOUNTED  ON  A  PCB 


An  electronic  box  must  be  capable  r,f  reliable  operation  in  a 
harsh  military  aircraft  environment  for  a  period  of  15  years 
An  examination  of  the  PCB’s  within  the  box  shows  that  there 
are  many  critical  components  such  as  DIPS,  hybrids,  pin  grid 
arrays  and  transformers  that  may  experience  broken 
component  lead  wires  and  cracked  solder  joints.  All  of  the 
critical  components  must  be  analyzed  to  make  sure  they  are 
capable  of  surviving  the  environments.  The  anaiysis  will  start 
with  the  transformer  .PA  mounted  on  the  PCB  as  shown  in 
Fig.  5  Every  critical  component  must  be  examined  to  insure 
the  reliability  of  the  system. 


040  Ota.  copper 
lead  wire 


Transformer  Mounted  on  a  PCB 
Figure  5 


The  PCB  and  the  transformer  arc  expected  to  operate  in  the 
following  environments  over  the  period  of  15  years: 


A: 

ESS  Random  vibration  screen 

PCS  response  1 1  2  G  RMS  3  axes. 

1.0  hr 

B: 

Capuve  flight  vibration 

PCB  response  6  1  G  RMS, 

2160  hr 

C. 

Free  flight  vibration 

PCB  response  15  9  G  RMS, 

1.0  hr 

D. 

Ground  transportation  vibration 

PCB  response  3.8  G  RMS, 

840  hr 

Where;  Ni  =  10®  Cycles  to  fail 
N2  =  10^  Q'cles  to  fail 
S 1  =  Endurance  =  1/3  S^,  (ulumate) 

Using  a  stress  concentration  factor  2: 


E.  ESS  Thermal  cycle  screen 

140  C  cycle  range 

50  cycles 

F:  Ground  alert  thermal  cycle 

44  C  cycle  range 

2700  cycles 

51  =  1/6  S 

52  =  Stu 


tu 


G.  Igloo  storage  thermal  cycle 
40  C  cycle  range 


2400  cycles 


Substitute  into  Eq.  (6) 

103'(i/6S,J 


or  Io5  =  6'' 


Take  the  log  of  both  sides  and  solve  for  the  exponent  b 


b^6.4 


(7) 


H:  Airborne  alert  thermal  cycle 

1 02  C  cycle  range  150  cycles 

T  he  random  vibration  qualification  test  consists  of  a  power 
spectral  density  input  (PSD)  of  0.15  0  square/Hz  for  a  period 
of  2  hours  per  axis,  or  a  total  time  of  6  hrs. 

Will  the  PCB  and  transformer  assembly  oe  capable  of 
surviving  these  environments  for  the  15  year^riod? 


DEMONSTRATION  OF  AVIP  TOOLS 

Sample  problems  are  a  convenient  way  of  demonstrating  the 
various  tools  that  are  available  for  evaluating  the  effecovc  life 
of  an  electronic  system.  In  this  case  a  transformer  mounted 
on  a  PCB  was  selected  because  experience  has  shown  the 
solder  joints  and  electrical  lead  wires  have  high  failure  rates 
in  thermal  cycling  and  vibration  environments.  Tlie  failure 
mechanisms  are  not  well  understood  because  they  are 
complex  and  require  a  great  amount  of  time  evaluate. 

The  transformer  (xfmr)  selected  was  the  largest  "-ize  that  can 


In  order  to  answer  this  question,  a  vibration  fatigue  analysis 
and  a  thermal  cycle  fatigue  analysis  must  be  performed  on  the 
PCB  and  on  each  of  the  most  critical  components.  In  this 
sample  problem,  only  the  transformer  will  be  examined. 

The  number  of  fatigue  cycles  accumulated  d'lring  vibration 
and  during  thermal  cycling  can  be  obtained,  then  combined 
using  Miner’s  cumulative  fatigue  damage  theory,  to  determine 
if  the  transformer  wiil  survive  the  combined  environments. 
Stan  with  the  random  vibration  qualification  test  to  establish 
the  desired  PCB  resonant  frequency  and  fatigue  life. 
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SOLUTION  -  RANDOM  VIBRATION  ENVIRONMENT 


The  desired  resonant  frequency  of  the  PCB  to  achieve  a 
fatigue  life  of  about  20  million  stress  cycles  for  the 
transforaier  can  be  determined  from  the  inllowing  relation  (7) 


fH  = 


29.4  Chr  ^  (it/2)(PSD)L 
0.00022  B 


(8) 


where:  C 

h 

r 

PSD 

L 


B 


=  1.26  Component  Type,  Xfmr 
with  bottom  lead  wires 
=  0.082  in  PCB  Thickness 
=  1.0  Relative  Position  at  Center  of  PCB 
=  0.15  G^/Uz  Power  Spectral 
Density  Input 

=  0.70  Inch  Length  Across  Lead  Wires 
on  Xfmr 

=  5.0  in  Width  of  PCB 


Substitute  into  the  above  equation: 


fd  = 


29.4(  1 .26)(0.082)  (.KP.)(.0.li)(0M 

000022(5.0) 


08 


PATIGUE  CYCLES  ACCUMULATED  IN  15  YEAR 
VIBRATION  ENVIRONMENT, 

CONDITION  A 

The  number  of  fatigue  cycles  required  to  produce  a  fatigue 
failure  for  Condition  A  can  be  determined  with  the  use  of  Eq. 
(1)  and  Eq.  (2)  as  follows. 


N1  =  N2 


V 


Gl 


Ref.  Eq.  (2) 


Where: 


02  =  32.8GRMsRcf  Eq.  (7) 

G 1  =11.2  Gr]^5  Ref.  Condition  A 


^2  =  20x10^  cycles  to  fail 
b  =  6.4  Exponent,  Ref.  Eq.  (7) 


N]  =  20x10' 


1^11.2^ 


6.4 


N]  =  1.939xl0'®  cycles  to  fail  (13a) 


This  represents  the  number  of  cycles  to  fail  for  the  1  (one  sigma) 
stress  level.  In  random  vibration,  acceleration  levels  two  times 
the  RMS  levels  can  occur,  and  acceleration  levels  three  times  the 
RMS  levels  can  occur. 


f(j  -  275  Hz  desired  frequency  (9)  Considering  the  2o  (two  sigma)  stress  accelerauon  condition: 


This  resonant  fluency  for  the  PCB  ts  only  valid  when  the 
“Octave  Rule”  is  used.  Octave  means  to  double.  The  PCB 
resonant  frequency  must  be  at  least  one  octave  away  from  the 
chassis  resonant  frequency  to  prevent  severe  dynamic 
coupling,  which  can  otherwise  shorten  the  fatigue  life. 


N2=  20x10® 


N2  =  229  6x10®  cycles  to  fail 


(13b) 


The  response  of  the  PCB  to  the  random  vibration  can  be 
determined  from  the  following  relation: 


GRMS  =  y(’^)(PSD)fnQ  (10) 

Where:  PSD  =  0.15  G^/Hz  PSD  input 

fn  =  275  Hz  PCB  Resonant  Frequency 

Q  =  JUS  =  166  Approximate 
PCB  Transmissibility  (7J 


Considenng  the  3(J  (three  sigma)  stress  acceleration  condition: 
64 


N3  =  20x10® 


^ 32  8 
V3(11.2i 


N3=  17. 14x10®  cycles  to  fail 


(13c) 


ACTUAL  NUMBER  OF  FATIGUE  CYCLES  (n) 
CONDITION  A 


Substitute  into  above  equation: 
Grms  =y(tV2)(0.15)(275)(16.6) 


QUALIFICATION  TEST  TIME  TO  FAIL 

The  estimated  time  for  a  failure  in  the  electncal  lead  wires 
and  solder  joints  can  be  determined  from  the  PCB  resonant 
frequency  and  the  20  million  cycle  life. 

_ 20x10®  cycles  to  fail 

Life=  cvcIes'N/^  sec's 

275  - I  3600  - 

sec  hr  y 


Life  =  20  2  hours 


(12) 


Since  the  qualification  test  lasts  for  a  total  of  6  hours  for  3 
axes,  the  design  should  be  satisfactory  for  the  qual  test 


The  actual  numbei  of  fatigue  cycles  accumulated  during  the 
random  vibration  environment  described  as  Condition  A  can 
be  detertruned  from  the  resonant  frequency  and  the  time.  A 
Gaussian  distribution  is  used  where  the  RMS  level  occurs 
68.3%  of  the  time,  the  2  (two  sigma)  level  occurs  27. 1  %  of 
the  time,  and  the  3  (three  sigma)  level  occurs  4.33%  of  the 
time  [7] 

nj  =  (275  cycle/sec)(3600  sec/hr)(1.0  hr)(0.683) 

nj  =  0.676x10®  cycles  accumulated 

n2  =  (275  cycle/sec)(3600  sec/hr)(1.0  hr)(0.271) 

n2  =  0  2b8x  10®  cycles  accumulated 

03  =  (275  cycle/sec)(3600  sec/hr)(1.0  hr)(0.0433) 

03  =  42.9x10^  cycles  accumulated 

FATIGUE  CYCLE  RATIO  n/N 

The  fatigue  cycle  ratio  n/N  can  now  be  computed  where  n  is 
the  actual  number  of  fatigue  cycles  accumulated  and  N  is  the 
number  of  fatigue  cycles  required  to  produce  a  failure. 


(14a) 

(14b) 

(14c) 
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n,  0.676  E6 

—  - -  =0.00003 

Nj  1  939E10 

n,  0  268E6 

—  - - =0.00117 

Nj  229.6  E6 

n-i  42.9  E3 

—  = - =000250 

N3  17.14  E6 


Adding  the  three  cycle  ratios  for  Condition  A' 
n 

—  =0.00003  +  0.00117  +  0.00250 
N 

n 

—  =0.00370  (15) 

N 

This  represents  the  cumulative  damage  developed  during 
Condition  A  vibration.  These  values  are  shown  in  Table  1. 
The  same  method  of  analysis  must  be  performed  for 
Conditions  B,  C,  and  D  for  the  vibration  levels  and  time 
designated.  The  results  are  shown  in  Table  1. 

SOLUTION  -  THERMAL  CYCLE  ENVIRONMENTS 


A,  =  rt/4  (0.04)2  _  0,00126  in^  wire 

A]  =  (6  wires)  0.00126)  =  0.00754  in^ 

a2  =  70xI0-6in/in/CTCEPCBZ 

L2  =  0.082/2  =  0.041  m  length  PCB 

E2  =0.1 5x  10^  lb/m2  Modulus  90  C 

A2  =  Area  PCB  to  Xfmr  Irregular 
Surface  50%  Contact  Area 

A2  =  (l/2)(it/4)(0.60)2  =  0.141  in2 

83  =  30x  10'^  in/in/C  TCE  Average 
Epoxy,  Steel,  Copper  Xfmr 

L3  =  0.75/3  =  0  25  in  effective  height  in  Xfmr 

E3  =  0.5x10^  Ib/in^  Average  Modulus 
Epoxy,  Steel,  Copper  Xfmr 

A3  =  0.141m2  Same  as  PCB 

Substiture  into  Eq  (16)  using  6  wires  for  the  transformer. 


Thermal  stresses  are  developed  in  the  lead  wires  and  solder  joints 
of  the  tran'formerduring  themial  cycling  exposure  as  defined  in 
Conditiot  ^  E,  F,  G,  and  H  for  the  15  year  environment 
See  Fig.  0 

Experience  has  shown  that  the  most  severe  condition  for  the 
transformer  will  be  the  thermal  expansion  along  the  Zaxis  which 
IS  perpendicular  to  the  plane  of  the  PCB.  The  thermal  induced 
forces  developed  in  the  electrical  lead  wires  of  tlie  transformer 
can  be  determined  from  the  equanons  of  equilibrium  In  the 
following  relation  the  subsenpts  1  refer  to  the  wire,  subscript  2 
refers  to  the  PCB,  and  the  subscript  3  refers  to  the  transformer. 
The  thermal  cycling  range  usexl  as  the  base  line  reference  is  from 
•55  C  to  +95  C,  or  a  delta  temperature  of  150  C. 


a^Ljdtj  + 


‘'1^1 
A, El 


=  a2L2dt2  + 


^2^2 

^2^2 


P3L3 

+  33!  +  —  '  —  (16) 

A3E3 

Where:  aj  =  17x10'^  in/in/C  Copper  TCE 

L]  =  Wire  length  2  dia.  into  PCB 
+  2dia  into  Xfmr 

L 1  =  2(0.04)+2(0.04)+0.020  =  0. 1 80  in 


P,  (0.18) 

(17E-6)(018)(75)+ - = 

(0.00754)(I6E6) 

P2(0041) 

(70E-6)(0  041)(75)-  - = -  + 

(0  14I)(0.15E6) 

P3  (0.25) 

(30E-6)(0.25)(75)  -  - - - 

(0.14I)(0.5E6) 


Pl=P2  =  P3 

0.000229  +  0.0000014P  =  0.000215  -  0.00000194P 
+  0.000562  -  0.00000355P 

Solve  for  P  force  in  6  wires 

P  =  78.5  lb  on  6  wires 

P=  13.1  lb  on  each  wire 

SOLDER  JOINT  SHEAR  STRESS  AT  WWE 

The  shear  stress  at  the  solder  join  for  the  wire  in  the  plated 
through  hole  can  be  determined  from  the  wire  diameter  of 
0.040  in  and  the  PCB  thickness  of  0.082  inches. 
Conservatively  ignore  any  solder  fillet  greater  than  the 
thickness  of  the  PCB.  This  will  result  in  a  slightly  higher 
solder  joint  shear  stress,  S, 

P 

Ss= -  (19) 

A 

Where:  P=  13.1  lb 

A  =  Tt(0.040)(0.082)  =  0.0103 

13.1 

Ss=  -  =  12721b/in2  (20) 

0.0103 


SOLDER  JOINT  STRESS  CYCLES  FOR  FAILURE 
ENVIRONMENT  CONDITION  F 


dtj  =  Average  Component  Temperature  Change 
from  -55  C  to  +95C 
dtj  =  (55  + 95)/2  =  75C  average 

Ej  =  16x10^  lb/in2  Modulus  Copper 


The  number  of  stress  reversals  or  stress  cycles  required  to 
produce  a  shear  failitre  in  the  solder  joint  can  be  deter 
mined  from  the  fatigue  S-N  curve  for  solder  as  shown  in  Fig. 
2,  along  with  Eq.  (1).  The  environment  conditions  for 
(jondition  F  were  used  to  demonstrate  this  tool  technique. 


I 
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The  reference  point  for  the  solder  was  at  600  psi  where  the 
expected  fatigue  life  was  about  5,000  stress  cycles. 


N,=N2 


Ref.  Eq.  (1) 


This  represents  the  cumulative  fatigue  damage  developed 
during  Condition  F  thermal  cychng  environment.  This  value 
is  shown  in  Table  2  The  same  method  of  analysis  must  be 
performed  for  Conditions  E,  G  and  H  for  the  thermal  cycling 
environment.  The  results  are  shown  in  Table  2. 

MINER’S  CUMULATIVE  FATIGUE  DAMAGE  FOR 
VIBRATION  AND  THERMAL  CYCLING 


Where.  N2  =  5000  cycles  to  fail 
S2  =  600  Ib/in^  to  fail 
dt  =  22  C  Condition  F  Temp  Delta 

22  “C 

S,  - - (1272)  =  373  lb/in2 

75  “C 


b  =  2.5  Solder  fatigue  exponent 


Nj  =  16,408  cycles  to  fail  (21) 


THERMAL  FATIGUE  CYCLE  RATIO,  CONDITION  F 


The  fangue  accumulated  during  vibration  can  be  added  to  the 
fatigue  accumulated  during  thermal  cycling  to  obtain  the 
combined  vibration  and  thermal  fatigue  effects  accumulated 
over  the  15  year  environment.  This  is  accomplished  by 
simply  adding  the  vibration  cycle  ratio  n/N  (.20544)  to  the 
thermal  cycle  rano  n/N  (.40933)  to  obtain  the  total  value.  The 
ni^imum  n/N  rano  allowed  is  0.70.  [7] 

n 

Rn=  -  =0.20544  +  0.40933 

N 

R„  =  0  61477  Total  Fatigue  (23) 

Damage  accumulation  is  linear,  so  it  is  possible  to  estimate 
the  expected  fatique  life  of  the  transformer  by  using  a  simple 
rano  as  follows: 


0.70 

Life  - -  (15  years) 

0.615 


Tue  thennal  fatigue  cycle  ratio  n/N  based  on  2700  thermal 
cycles  expected  for  the  15  year  exposure  defined  in  Condinon 
F  can  be  determined  as  follows: 

n  2700 

-  =  — —  =  0  16455  (22) 

N  16,408 


Life  =  17.1  years  (24) 

The  maximum  allowable  n/N  rano  for  elecnonic  equipment 
is  0.70.  Since  the  above  value  is  smaller,  the  equipment 
design  is  adequate  for  the  15  year  environment,  based  upon 
the  nansformer  analysis.  The  same  type  of  analysis  must  be 
performed  on  every  critical  component  on  e-.eo'  PCB. 


TMU:  1  VHHATIOH  osTtSUE  u,  £  9r..TiagW71g.ht*°  JOllEL 


COrClTION 

- 

B 

C 

D 

PCB  vibration  C  RHS  response 

11.2 

6.1 

15.9 

3.8 

Vibration  tlae  for  IS  years,  hours 

l.O 

2160 

l.O 

840 

hj  (l^  )  actual  fatigue  cycles 

.67«xlO* 

I .46xlo’ 

.676x10* 

568x10* 

n2  (2(r  )  actual  faclgua  cycles 

.268x10* 

579.5x10* 

.268x10* 

255.4x10* 

(3  ^  )  actual  fatigue  cycles 

42.9x10^ 

92.6x10* 

42.9x10* 

36,0x10* 

N|  (19*)  cycles  to  fall 

1.939x10“’ 

9.5xl0“ 

2.059x10* 

1.959x10** 

N2  (28')  cycles  to  fall 

229.6x10* 

1.122x10** 

24.38x10* 

2,32x10** 

Nj  <3  0  cycles  to  fall 

17.14x10* 

837.4x10* 

1.82x10* 

1.73x10*° 

Aj/Nj  (1  <r  )  ratio 

.00003 

.00154 

.00033 

.00003 

n2/N2  (2  <r  )  ratio 

.00U7 

.03165 

.01099 

.00097 

a^/N<j  Of)  ratio 

.00250 

.11058 

.02357 

.00208 

S\a  of  n/N  for  each  Condlt  on 

,00370 

.16377 

.03489 

.00308 

VltrAClQn  cyel«  n/N  J5  yaars  •  .00370*,1C377*.03489+. 00308  ■  ,20544 

Thlf  iva  oust  bt  addad  to  tha  chdraal  cycle  faclgua  to  obtain  the  total  fattguo» 
Which  Is  ahovn  in  (23)  abova* 


TABLE  2  THtJWaL  CYCLE  FATIGUE  Lift  OF  TMNSrORHa  LEAD  WTBr!^ 


CONDITION 

Z 

f 

G 

H 

Actual  teoperature  range 

140  “c 

44  °c 

40  ®c 

102  °C 

Teaperature  range  used  for  stress 

70  C 

22  C 

20  C 

51  C 

Soldsr  shear  stress  Ib/ln^ 

1186 

373 

339 

864 

n  Actual  nuaber  eyelss  aecvasulated 

50 

2700 

24C0 

150 

N  Nuaber  of  cycles  for  failure 

910 

16,408 

20,838 

2,009 

Racioi  n/N  for  each  Condition 

.05495 

■16455 

.11517 

.07466 

Tharaal  faclgua  cycla  n/N  luna  15  yaara  •  .0S49S*«16455*>11S17+. 07466  ■  .4^933 

Thla  •va  auac  ba  added  to  tha  vibration  Caclgua  cycle  to  obtain  the  total  faciAua* 
Which  Is  shown  in  Eq.  (23)  abovof  and  repeatad  balow  as  follovsi 


Total  fatlaue  ratio  R  ■  —  •  .20544  ♦  .40933  •  .61477  Raf.  Eq.  (23) 
n  ■ 
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Footnotes: 

1.  Rebabihtv  of  Military  Electronic  Equipment,  prepared  bv 
the  Advisory  Group  on  Reliabdity  of  Electronic  Equipment, 
Office  of  the  Assistant  Secretary  of  Defense  (Research  and 
Engineering),  4  June  1957. 

2.  RADC/RBER  is  the  custodian  for  MIL-HDBK-217,  and  is 
the  responsible  government  agency  for  maintaining  the 
document,  coordinatitig  changes  and  updating  the  document 
as  necessary. 

3.  DoD  4120.3-M.  Defense  Standardization  and  Specification 
Program  Policies.  Procedures  and  Instructions.  Office  of  the 
Under  Secretary  of  Defense  for  Research  and  Engineering, 
Washington  D.  C.  20301,  August  1978. 

4.  MIL-HDBK-217E  included  for  the  first  rime  a  failure  rate 
prediction  technique  for  Interconnection  Assemblies  with 
Plated  Through  Holes  and  Connections  (solder  joints).  The 
primary  failure  mechanism  for  properiy  made  PTHs,  vias,  and 
solder  joints  process  is  fatigue,  a  process  that  is  deterministic 
in  nature  An  appropriate  life  prediction  would  address  the 
magnitude  and  number  of  cycles  to  first  failure  rather  than  a 
failure  rate  as  provided  by  MIL-HDBK-217.  The  life  of  the 
PTHs  and  vias  depends  on  the  cumulative  stresses  applied 
(thermal  cycling  and  vibration),  the  thickness  of  the  printed 
wiring  board,  the  coefficients  of  expansion  of  the  board 
materials,  the  thickness  of  the  PTHs  and  vias  plus  the 
metallurgy  (composition  and  grain  structure)  of  the  copper 
plates.  A  sitmlar  set  of  variables  govern  the  life  of  the  solder 
in  the  joint.  Thus,  the  idea  that  the  failure  rate  model 
contained  in  MIL-HDBK-217  is  an  over  simplification  at 
best 

The  followmg  technical  papers  provide  adrlitional  insight: 

“Some  Aspects  of  Solder  Joint  Fatigue  During  Thermal 
Cycling,"  Ronald  G.Lambett,  General  Electnc,  giS  Annual 
Technology  Meeting.  May  1987. 

“Impact  of  External  Lead  Design  on  the  Fracture  of  HIC- 
PWB  Assemblies  Subject  to  Bending,"  T.  F.  Marinis,  R.  C. 
Reinert,  W.M.  Sherry,  AT&T  Bell  Laboratoiy,  1984. 

“Mechanical  Reliability  for  Low  Cycle  Fadgue,”  Ronald  G. 
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IMPLICATIONS  OF  INTEROPERABIUTV’  AND  STANDARDIZATION 
FOR  THE  INDUSTRIAL  BASE 

DR.  JOHN  C.  STUELPNAGEL 
VWNAGER,  DIGITAL  SYSTEMS 
WESTINGHOUSE  ELECTRIC  CORPORATION 
BALTIMORE,  MARYLAND  21203 


SUMMARY 


A  persistent  problem  for  NATO  forces  has  been  the  difficulty  of  standardization  and  interoperability,  due  to  conflicting 
political,  economic,  national  and  industrial  pressures.  One  approach  to  better  accomplish  standardization  objecfives  has  been 
the  establishment  of  co-dev(  lopment  programs,  such  as  the  VHSIC  Avionics  Modular  Processorprogram,  in  which  thefi-ench 
and  United  States  Governments  have  initiated  the  development  of  interoperable  digital  processing  modules.  However,, 
conflicts  in  timing  between  development  efforts  and  schedules  for  production  and  deployment  of  airaaft  platforms  has 
resulted  in  limited  use  of  such  modules  in  major  aircraft  programs.  Several  models  for  NATO  standardization  orgamzations 
will  be  discussed  which  could  address  this  problem  and  achieve  significantly  higher  levels  of  interoperability  in  operational 
NATO  equipment. 

INTRODUCTION 

Good  mornino,  distinguished  visitors  to  the  AGARD  Lecture  Senes.  Thank  you  for  inviting  me  to  present  the  industrial 
point  cf  view  on  this  important  issue. 

Tlie  previous  speakers  provided  a  comprehensive  historical  review  of  avionics  architecture,  software,  and  hardware 
standardization.  The  afternoon  speakers  will  address  avionics  technology  and  needs  beyond  2000. 1  feel  that  the  implications 
of  interoperability  and  standardization  for  the  industrial  base  is  appropriately  placed  at  this  point  in  the  .schedule  because  the 
'.let Ironies  industrial  base,  which  clearly  impacts  on  avionics,  is  the  link  between  where  we  are  today  and  where  we  will  go 
tomorrow. 

Before  addressing  the  specifics  of  my  subject,  1  will  present  my  view  of  the  electronics  environment  in  today’s  world. 
Unlike  some  technologies  which  are  driven  by  the  military  market,  and  others  which  are  driven  by  the  commercial  market,  the 
electronics  technology  is  driven  by  both  the  military  and  commercial  marketplace.  That  is ,  electronics  is  a  shared  technology. 
Military  developed  electronics  have  flowed  to  the  commercial  market,  and  we  see  more  and  more  commercially  developed 
'ilectronics  flowing  to  defense  applications. 

Electronics  is  also  characterized  by  rapid  growth  and  change.  This  is  obvious  to  all  of  you  who  work  in  the  industry.  This 
rapid  growth  and  change  significantly  impacts  on  the  the  industrial  base  as  well  as  the  customer  base,  especially  relative  to 
attempts  to  define  and  implement  standards. 

Finally,  electronics  is  very  big  business,  an  expen-  business,  and  a  very  competitive  business. 

IMPLICATIONS  or  INTEROPERABILITY  AND  STANUAKUIZATTON 

For  the  purpose  of  this  paper,  I  will  focus  on  avionics  standardization  in  the  simplest  of  terms,  rather  than  the  global 
definitions  of  standardization  and  interoperability.  My  reason  for  doing  this  is  to  avoid  the  economic  and  political 
implications  that  surround  both  macro-level  issues  and  to  concentrate  on  the  micro-level  issues  of  standardized  avionics. 
More  specifically,  I  will  F'  zin  by  discussing  what  a  standard  is  and  who  sets  the  do  facto  standard  in  the  broadest  sense.  I  will 
then  proceed  into  the  >.  cations  of  standardization  as  it  applies  to  avionics. 

If  I  were  to  ask  this  group  to  define  a  standard  and  identify  the  body  which  sets  the  standard,  I  am  sure  that  we  would  have  a 
lively  discussion.  From  my  perspective  in  industry,  I  will  state  simply  that  the  standard  is  that  which  is  accepted  by  the 
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competitive  marketplace,  and  that  the  customer  base  establishes  the  de  facto  standards.  In  essence,  the  standard  evolves 
through  acceptance  of  a  product  by  the  consumer. 

For  example,  let  us  look  at  the  personal  computer  market.  The  Personal  Computer  (PC)  is  the  standard  because  of  its 
overwhelming  market  share.  Although  there  are  other  personal  computers  in  the  marketplace,  the  majority  tend  to  be  PC 
clones,  with  Macintosh  being  the  notable  exception.  The  fundamental  reason  is  economics,  both  for  the  customer  and  the 
manufacturers  of  PC  compatible  hardware,  software  applications,  and  compilers. 

Because  Personal  Computers  dominated  the  market  initially  and  provided  a  lucrative  business  opportunity  for  other 
sectors  of  the  electronics  industry,  vast  amounts  of  capital  were  invested  m  supporting  software,  compilers  and  peripheral 
hardware.  If  your  hardware  or  software  was  not  compatible  with  the  Personal  Computer  standard,  you  were  required  to 
develop  the  interface  necessaiy  in  order  to  market  your  innovation. 

Like  hardware  standardization,  software  also  evolves  through  acceptance  and  use  in  the  market.  For  example,  the 
COBOL  computer  language  accounts  for  85%  of  all  software  applications  in  the  world,  followed  by  “C”  language  which  has  a 
7%  share,  and  all  remaining  languages  a  mere  8%  of  the  world  market.  Again,  the  market  established  the  de  facto  standard. 

F-16  AVIONICS 

The  avionics  business  is  very  similar  to  the  personnel  computer  business.  In  terms  of  a  standard,  the  F-16  has  become  the 
PC  of  modern  day  fighter  aircraft  simply  because  it  has  gained  customer  acceptance  and  has  been  fielded  in  relatively  large 
quantities  throughout  the  world.  Consequently,  the  F-16  avionics  have  evolved  as  the  avionics  standard  for  the  US  and  many 
of  its  allie.s. 

A  network  of  personal  computers,  or  general  purpose  processors,  is  very  much  like  aircraft  avionics  which  is 
fundamentally  a  network  of  integrated  and  custom  designed  processors  (computers)  linked  to  a  variety  of  sensors  or  weapons 
systems. 

Initial  performance  specifications  developed  for  PCs  were  based  on  market  surveys  and  analyses  of  perceived  customer 
needs;  the  process  used  by  the  USAF  was,  in  many  ways,  very  similar.  Laboratories  developed  specifications  based  upon  the 
perceived  needs  of  using  commands  based  upon  surveys  and  analyses  of  threat  capabilities. 

Tlie  result  was  a  system  architecture  that  focused  on  the  integration  of  avionics  sub-systems  through  the  use  of  a  set  of 
specifications  for  a  “Bus"  and  “Central  Processing  Unit.”  That  is,  the  specifications  focused  on  the  interfaces  between 
systems.  So  long  as  the  subsystems  were  compatible  with  the  Bus  and  CPU  specifications,  the  design  of  the  sub-systems  was 
constrained  only  by  performance  requirements.  The  advantage  of  this  architecture,  based  on  interface  specifications  between 
subsystems,  was  that  incremental  improvements  or  additions  to  the  avionics  suites  could  be  integrated  without  a  total  redesign 
of  the  avionics  system. 

Standardization  in  the  F-16  program  centered  on  the  1553  Bus  and  tne  1750  CPU  ."he  Avionics  Subsystems  simply  had 
to  meet  these  interface  requirements. 

LH  AND  ATF  AVIONICS 

In  the  ATF  (now  the  F-22)  and  LH  (now  the  RAH-66  Comanche)  programs,  a  modular  avionics  architecture  will  be  used. 
Rather  than  focusing  on  a  standard  interface  between  subsystems,  the  standard  interface  will  be  the  backplane  between  data 
and  signal  processing  modules.  Module  designs  for  data  processing  will  use  the  INTEL  80960  32-Bit  CPU,  and  Ada  software. 

Despite  having  standard  specifications,  we  still  have  not  “standardized  ”  modular  avionics  in  the  LH  and  ATF.  The 
“standardization”  evolution  is  progressing,  however,  now  that  the  contracts  for  the  Lockheed  YF-22  and  the 
Boeing-Sikorsky  Comanche  were  awarded.  The  Intel  80960  CPU  will  be  the  standard  avionics  processor  in  both  systems  and 
Ada  will  be  the  standard  language.  Had  the  Northrop  YF-23  been  selected  for  the  ATF,  the  MIPS  CPU  would  have  been  used 
and  this  opportunity  tor  standardization  across  platforms  would  have  disappeared.  Through  chance  rather  than  design,  a  level 
of  standardization  will  be  achieved  for  the  peripheral  compiler. 

With  regard  to  the  backplane,  or  the  use  of  common  modules  in  the  RAH-66  Comanche  and  F-22,  the  issues  are  still 
being  worked.  A  significant  opportunity  for  the  use  of  common  modules  in  both  ^tems  lies  ahead  of  us.  Although  both 
programs  were  originally  intended  to  have  identical  specifications  for  the  modular  processors  that  were  developed  through 
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the  JIAWG  and  MASA,  development  of  the  modular  processors  is  being  done  by  different  electronics  companies  and  may 
have  differences  in  implementation  details  that  make  them  non-identical. 

The  fundamental  fact  is  that  standard  specifications  do  not  necessarily  lead  to  interoperable  equipment.  Unless  the 
avionics  and  avionics  integration  were  being  accomplished  by  the  same  company,  and  cost,  schedule,  operating  system  and 
performance  supported  standardization  between  both  systems,  complete  and  total  standardization  would  probably  not  be 
achieved. 

TIMING 

Major  aircraft  programs  influence  avionics  standardization  more  than  do  STANAGS  or  standardization  studies.  The 
reason  is  that  the  aircraft  program  wib  take  advantage  of  the  state-of-the-art  electronic  technologies  during  the  development 
period.  In  turn,  the  standards  evolve  for  that  generation  of  aircraft.  Without  a  vehicle  (airaaft)  to  standardize  to,  a  set  of 
specifications  will  not  make  the  transition  from  paper  to  hardware. 

Tike  for  example  the  current  multi-national  ASAAC  (Allied  Standard  Avionics  Architecture  Council).  The  purp  ose  of 
the  Council  is  to  develop  a  standard  avionics  architecture.  The  resulting  product  will  not  be  ready  for  the  F-22,  EFA,  and  the 
RAFALE  programs  which  are  already  in  development.  In  fact,  industry  is  pressing  forward  with  the  F-22,  EFA,  and  RAFALE 
avionics  architectures.  Ultimately,  whatever  documeut  emerges  from  ASAAC,  will  be  of  little  immediate  application,  unless 
there  is  a  major  avionics  upgrade  to  these  aircraft.  In  alt  likelihood,  the  ASAAC  results  would  be  used  as  a  point  of  departure 
for  future  program  specific  requirements. 

The  standardization  issue  at  the  national  level  in  the  US  is  less  complex  than  that  at  the  international  level,  however,  the 
outcome  is  generally  the  same;  we  fall  short  of  ambitious  objectives.  Ideally,  the  JIAWG  should  have  established  an  avionics 
architecture  standard  for  the  LH,  ATF,  and  ATA.  In  reality,  it  could  not.  The  program  cost,  schedule,  and  performance  were 
and  will  continue  to  be  the  over-nding  factors.  Standard  Avionics  will  likely  be  relegated  to  a  second  or  third  tier 
consideration  in  program  decisions. 

The  industnal  perspective  is  quite  simple:  meet  the  cost,  schedule  and  performance  requirements  first  and  foremost. 
Standardization  will  evolve,  to  whatever  extent  is  practicable  during  FSD  and  be  fixed  during  production. 

MODULAR  AVIONICS 

One  research  program  in  the  US  which  has  had  a  profound  effect  on  the  current  generation  of  avionics  which  will  be  used 
in  the  RAH-66  Comanche  and  F-  22  programs  and,  as  well,  in  the  F-16  Mid  Life  Update  program  is  the  USAF  VHSIC 
Avionics  Modular  Processor  (VAMP).  This  research  and  development  effort  focused  on  a  processing  requirement  several 
orders  of  magnitude  greater  than  the  previous  generation  of  avionics.  The  architecture  was  driven  by  the  electronic 
advancements  m  a  variety  of  sensor  systems  and  weapons  systems  that  demanded  vastly  more  powerful  processing  that  could 
integrate  the  data  in  real  time. 

In  the  early  1980’s,  the  data  and  signal  processing  requirements  for  the  new  generation  of  integrated  sensor  and  weapons 
^tem  requirements  were  addressed  in  a  coordinated  research  plan.  Concurrently,  JIAWG  and  MASA  monitored  and 
directed  the  research  to  make  the  most  advantageous  use  of  electronics  developments  in  both  the  commercial  and  militaiy 
communities 

'fhe  architecture  envisioned  the  use  of  a  High  Speed  Fiber  Optic  Data  Bus  for  transfer  of  raw  data  in  the  50MHz  range, 
massively  parallel  array  processors  for  signal  data  in  the  range  of  500-750  MOPS,  the  instantaneous  transfer  of  processed 
signal  data  to  a  digital  processor,  SEM-E  modules,  and  higher  speed  32  bit  RISC  processors,  integrated  into  a  single  modular 
avionics  processor. 

The  ba.-.’c  rcNt..  c’’  on  inodiru'  .i-/iom..s  wnv  v“!x  successful.  The  product  of  the  US  effort  was  a  modular  data  processor 
that  in  ,1' '  i-  i  'fiO.'v  CPU  Mc.lule,  a  1553  Data  Bus  Module.  The  research  was  extended  to  the  international  community  via 
cooperaic  .■  Jeve'opiiieni  projects  witn  .'-ranee  and  Germany.  The  French  VAMP  program  addressed  the  integration  of  a 
Non-Vola'.'fc  'vicm'...y  .Mo'Ju'e,  and  a  32  Bit  58020-tiased  CPU  processing  module.  The  German  VAMP  program  will 
incorporate d'spl'n  ir'  '  s  Ineachc!ementoftheprogram,valuableinsightsweregainedbyboththemilitaryandindustrial 
participants. 
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These  insights  laid  the  groundwork  for  the  RAH-66  Comanche  and  F-22  program  specifications  for  full  scale 
development.  Without  the  concurrent  R&D  effort  and  full  participation  by  both  government  and  industry,  the  avionics 
packages  envisioned  for  the  RAH-66  Comanche  and  F-22  would  not  have  progressed  to  this  point. 

MILITARY  -  INDUSTRIAL  COOPERATION 

Key  to  the  military  avionics  standardization  process  m  todays  electronic  environment  is  military-industrial  cooperation 
beginning  dunng  the  basic  research  phase  of  aviomcs  concept  development  and  continuing  through  Full  Scale  Development. 
This  cooperation  should  be  accomplished  at  both  the  national  and  international  level  on  a  continuing  basis  if  it  serves  no  other 
purpose  than  to  establish  a  baseline  of  departure  for  potential  cooperative  programs. 

As  1  discussed  earlier,  the  RAH-66  Comanche  and  F-22  avionics  speafications  were  greatly  influenced  by  the  success  of 
the  modular  avionics  research  program  as  well  as  the  JIAWG  and  MASA  efforts  in  the  US.  The  US  military  and  US  industry 
were  positioned  to  take  full  advantage  of  the  lessons  learned  in  the  research  effort  and  apply  them  m  a  relatively  short  time  to 
the  FSD  programs.  Program  cost,  schedule  and  technical  risk  were  reduced  to  an  acceptable  level. 

At  the  international  level,  ASAAC  provides  the  same  opportunity  for  future  aviomcs  programs  if  their  work  is  tied  to 
cooperative  research.  However,  some  major  obstacles  must  be  overcome  before  ASAAC  can  achieve  mutually  acceptable 
results  for  all  participants. 

The  US  is  in  a  position  to  offer  a  baseline  for  future  avionics  architectures  but  there  appears  to  be  an  unwillingness  of  the 
European  participants  to  accept  the  US  JIAWG  and  MASA  products  as  a  point  of  departure.  Lacking  an  agreement  on  the  US 
work  as  a  point  of  departure,  the  US  would  get  no  return  on  any  investment  that  requires  a  return  to  basic  studies  that  have 
already  been  completed  .  The  reluctance  of  the  European  partidpants,  on  the  od'er  hand,  to  "ccept  the  US  baseline  is 
understandable  since  their  military  needs  and  their  industrial  investments  may  not  be  satisfied  by  the  US  baseline. 

The  timing  for  ASAAC  may  simply  not  be  m  the  best  interest  of  all  participants  in  the  absence  of  a  major  international 
program  to  which  the  results  could  be  applied.  Nonetheless,  a  mutual  understanding  of  the  leading  edge  electronics 
technology  by  both  the  military  and  industrial  partidpants  is  needed  to  establish  a  baseline  technological  approach.  To  this 
end,  in  the  absence  of  a  multi-national  program,  NATO  should  establish  an  entity  that  would  maintain  an  up-to-date  set  of 
avionics  electronics  specifications. 

The  pnndpal  issue  to  be  decided  is  whether  or  not  an  organization  dedicated  to  the  maintenance  of  an  up-to-date  set  of 
baseline  avionics  electronics  specifications  is  of  value.  Once  this  issue  is  decided,  the  type  of  organization  and  funding  sources, 
either  government,  industry,  or  private,  or  any  combination  thereof,  can  be  addressed.  The  full  range  of  standardization 
organizations  exists  today,  from  those  staffed  and  funded  by  the  government  to  those  which  are  non-profit  foundations 
supported  by  grants  from  industry. 

SOME  MODELS  FOR  STANDARDIZATION 

As  you  are  well  aware,  a  standardization  organization  or  multiple  standardization  organizations  for  everything  from  soup 
to  nuts  exist.  If  a  standard  does  not  exist,  someone  will  evenmally  fill  the  void.  These  organizations  come  in  all  sizes  and 
shapes.  My  purpose  is  simply  to  identify  a  few  different  types  of  organizations  which  influence  standards  in  the  'ximmercial  and 
military  electronics  arena  that  could  be  used  as  a  model  for  future  militaiy  avionics  requirements  m  the  international  arena. 
These  organizations  include,  but  are  certainly  not  limited  to  the  following: 

Aeronautical  Radio,  Incorporated  (ARINC)  -  A  private  corporation  that  coordinates  Communications  and  Avionics 
Standards  among  the  airlines  and  the  airframe  manufacturers.  Much  of  this  work  is  accomplished  through  open  forums  on 
avionics  specifications,  aircraft  installation  provisions,  and  standards  for  test  equipment. 

Airlines  Electronic  Engineering  Committee  (AEEC)  -  A  special  organization  within  ARINC  which  is  fully  funded  by  the 
airframe  manufacturers.  It  is  the  focal  point  for  the  commercial  airframe  manufacturers  and  avionics  equipment  designers, 
the  Federal  Aviation  Administration,  and  the  intemattonal  aviation  community  to  develop  the  next  generation  avionic 
guidance  and  specifications  for  commercial  modular  avionics. 

Open  Software  Foundation  (OSF)  -  OSF  is  incorporated  as  a  non-profit,  industry  supported  research  and  development 
organization.This  international  organization  was  aeated  to  define  specifications,  develop  leadership  software,  and  make 
available  an  open,  portable  software  environment.  The  foundation  complements  the  work  of  various  worldwide  software 
organizations,  and  will  provide  implementations  consistent  with  those  standards. 
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Next  Generation  Computer  Resources  (NGCR)  -The  US  Navy,  under  the  auspices  of  the  NGCR,  has  established  a  Project 
Support  Environment  Standards  Working  Group  (PSESWG).  The  purpose  of  this  US  Navy  funded  joint  mdustry/US  Navy 
working  group  is  to  establish  interface,  protocol  and  service  standards  for  mandatory  use  in  future  US  Navy  systems 
developments  The  specific  objective  is  to  select/define  a  set  of  industry-based  standards  to  form  an  “open”  framework  for 
project  support  environment  tools,  user  interfaces,  database  management  systems,  which  will  be  applied  in  the  development 
and  maintenance  of  future  US  Navy  programs. 

These  are  but  a  few  organizations  which  are  focusing  on  the  next  generation  of  hardware  and  software  for  electronic 
systems.  The  common  thread  between  these  organizations  is  an  attempt  to  establish  a  comprehensive  baseline  with  respect  to 
state-of-the-art,  evolving  technologies,  in  the  electronics  world. 

CONCLUSION 

The  concepts  and  ideal  of  interoperability  and  standardization  are  fully  appreciated  and  embraced  at  the  national 
resource  level.  The  reality  of  standardized  avionics  does  not  approach  the  grand  concepts.  Philoiiophically,  however,  we 
should  not  abandon  these  concepts,  otherwise  total  chaos  would  reign.  As  imperfect  as  the  process  and  as  elusive  as  the  goals 
may  be,  any  movement  toward  that  goal  is  commendable  and  worth  the  effort. 

The  degree  to  which  standardization  is  achieved  is  a  function  of  products  accepted  by  the  customer.  Without  a  product  and 
a  customer,  standards  exist  only  on  paper.  This  is  the  case  in  both  the  commerdal  and  militaty  market. 

Standards  m  the  commercial  processor  market  ate  evolutionary  and  guaranteed  to  be  de  facto  standards.  In  the  military 
market,  standard  specificaf'on.',  are  provided,  however,  they  in  themselves  do  not  guarantee  a  standard  product.  TWo 
competitors  designing  a  piece  of  hardware  to  the  same  specification  will  undoubtedly  produce  noncompatible  components. 
One  would  assume  that  since  the  RAH-66  Comanche  and  F-22  avionics  interface  specifications  were  identical,  modules 
would  be  interchangeable,  but  this  is  not  assured  to  be  the  case.  Despite  the  efforts  of  JIAWG  and  MASA,  agreement  on  a 
CPU  could  not  be  reached  prior  to  contractor  seleaion.  Through  chance,  the  winning  contractors  both  selected  the  INTEL 
CPU,  and  degrees  of  standardization  will  be  achieved  through  the  use  of  a  common  compiler. 

In  the  environment  where  program  cost,  performance  and  schedule  dominate  the  decision  process,  and  standardization  is 
a  second  or  third  tier  consideration,  total  stand.ardization  will  not  likely  be  achieved  on  the  national  level.  Internationally, 
where  operational  requirements  must  be  harmonized  before  a  development  and  production  decision,  and  national  political 
and  economic  considerations  are  also  dominant,  the  achievement  of  international  standardization  becomes  even  more 
difficult. 

The  greatest  opportunity  for  international  standardization  in  military  avionics  will  come  from  government  sponsored 
ASAAC  -  like  activities  when  a  target  airframe  is  identified  and  a  cooperative  development  is  initiated.  Again,  however,  the 
standardization  will  be  limited  to  that  particular  aircraft.  The  aircraft  market  is  so  small  and  developments  so  separated  by 
lime  and  growing  requirements  that  total  standardization  amongst  the  total  fleet  of  aircraft  is  unreasonable  to  expect. 

Industry,  on  the  other  hand  should  not  realistically  expect  their  respective  governments  to  maintain  updated 
specifications  for  electronics .  I  suggest  that  government  and  industry,  on  both  the  national  and  international  levels,  should 
pursue  the  establishment  of  an  organization  to  maintain  electronics  standards  for  avionics  that  could  be  applied  to  military 
avionics.  In  the  absence  of  an  international  co-development  program,  this  is  the  most  logical  and  supportable  alternative.  The 
information  could  be  used  by  the  military  as  an  information  baseline  for  developing  military  specifications  that  will  lead  to  the 
greatest  degree  of  industrial  standardization. 

In  closing,  the  implications  of  interoperability  and  standardization  for  industries  involved  in  the  avionics  business  is  still 
driven  by  the  military  o.  ganization.  We  will  build  to  whatever  standard  the  customer  desires,  provided  ihat  the  opportunity  to 
make  a  profit  is  presented.  In  order  to  be  in  a  posit, on  to  win  the  business,  we  must  stay  abreast  of  the  state-of-the-  art  design, 
engineering,  and  manufacturing  processes  of  the  electronics  industry  and  provide  a  competitively  priced,  quality  product  that 
meets  cost,  schedule  and  performance  requirements.  The  latter  are  the  most  important  standards  for  long  term  survival. 
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SUMMARY 

If  current  trends  continue,  military  avionics  will 
face  a  very  difficult  situation  at  tlie  turn  of  the 
century.  This  situation  is  predicted  despite 
impressive  strides  made  in  avionics  performance, 
reduced  weight  per  function,  reduced  cost  per 
function,  and  a  steady  improvement  in  hardware 
reliability  over  the  past  20  years. 

We  want  and  need  affordable  performance  with 
little  or  no  support  required.  However,  the 
projected  avionics  performance  improvements 
needed  for  increased  situation  awareness  and 
automation,  the  escalating  costs  of  software  and 
sensors,  and  the  manpower  and  ground  facility 
support  limitations  imposed  by  austere  base 
operation  are  currently  incompatible.  If  we  are 
unable  to  achieve  a  reasonably  balanced 
affoidability/availability/performance  capability 
triad,  there  will  be  no  other  option  than  to 
substantially  reduce  either  the  number  of  weapon 
systems  or  their  war-fighting  capability. 

The  basic  architectural  framework  and  modular 
avionics  strategy  (viz.,  PAVE  PILLAR)  needed  to 
achieve  this  triad  will  soon  be  in  place.  Most  of 
the  needed  enabling  technologies  are  under 
development.  The  next  step  will  be  to  carefully 
exploit,  integrate,  and  validate  these  technologies 
in  bold,  innovative  ways.  Dramatic  changes  will 
be  needed  in  the  way  we  integrate  and  share 
sensor  functions;  in  the  way  we  develop  and 
support  software;  and  in  the  design  environments 
we  use.  Some  of  these  changes  will  induce 
“culture  shock”  and  will  not  be  welcomed  at  first. 
However,  the  authors  believe  that  the 
improvements  needed  in  future  avionics  cannot  be 
realized  by  evolutionary  methods. 

1.  CmiENOES  FOR  EARLY  21ST 
CENIURY-AYIQMICS 

Tnis  section  contains  the  authors’  opinions  of 
the  projected  factors  that  will  fundamentally 


impact  future  avionics  systems  and  the 
implications  of  these  factors. 

The  Need  to  Improve  Performance 

It  is  reasonable  to  project  that  stealth  will 
become  a  primary  design  consideration  for  mar. 
new  airborne  military  systems.  Achieving 
avionics  stealth  while  providing  sufficient  data  to 
inform  the  aircrew  of  threat,  terrain,  and  targeting 
information  implies  the  following: 

a.  Electronic  Support  Measures  (ESM)  and 
Infrared  Search  and  Track  (IRST)  passive  sensors 
will  be  increasingly  important  on-board  sources  of 
information  for  air-to-air  missions;  use  of 
Forward  Looking  Infrared  (FLIR),  laser  radar 
(LADAR),  stored  terrain  data,  and  power 
managed  radars  will  be  the  primary  on-board 
sensors  for  air-to-ground  missions. 

b.  Externally  derived  data  (bistatically 
developed,  from  Joint  Tactical  Information 
Distribution  System,  etc.)  will  need  to  be 
integrated  to  complement  on-board  sensors. 
Additionally,  flight-wide  to  force-wide 
exchange/coordination  of  data  will  become  much 
more  important. 

c.  Active  sensors  will  still  be  required,  but 
they  will  be  designed  with  low  probability  of 
intercept  characteristics.  They  will  be  invoked 
and  controlled  through  automated  means  to 
complement  passively  derived  data.  Sensor 
control  strategies  will  be  extremely  complex  with 
parameters  such  as  signal  strength,  dwell  time, 
and  beam/null  steering  being  carefully  controlled. 

d.  Significantly  enhanced  automating  aids  will 
be  required.  Use  of  artificial  intelligence  and 
neural  network  technologies  will  be  needed  to 
routine  y  aid  pilot  decision  aiding.  Automatic 
targe;  recognition  for  both  ground  and  air  targets 
will  become  mandatory. 
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e.  Data  from  on-board/off-board  passive 
sources,  integrated  sources,  and  active  sources 
will  need  to  be  fused  and  coordinated  as  a 
function  of  dynamic  mission  situations.  On-board 
actively  derived  data  from  radar, 
communication/navigation/identification  (CNI), 
and  electronic  warfare  (EW)  will  need  to  be 
integrated. 

Achieving  these  capabilities  will  require 
significant  advances  in  sensors  and  sensor  signal 
processing.  We  will  need  to  put  the  equivalent  of 
teraop  (10*^  operations)  super  computers  into 
future  avionics. 

The  Need  for  Lower  Avionics  Costs 

Achieving  stealthy  situation  awareness  from  an 
airborne  platform  could  conceivably  become  so 
complex  and  costly  as  to  prohibit  its  widespread 
use.  Tlie  software  complexity  alone  could 
overwhelm  us.  Consider  the  massive  costs  and 
difficulty  being  experienced  today  for  “simple” 
software;  and  then  consider  how  we  will  ever 
design,  develop,  and  debug  real-time  artificial 
intelligence  (AI)-ba.s';d  software  that 
simultaneously  controls,  fuses,  and  reconfigures 
such  a  complex  system  across  diverse  systems. 
When  one  considers  the  enormity  of  the  cost  and 
effort  of  developing  and  supporting  the  software 
across  several  aircraft  having  complex  sensor 
systems,  it  becomes  apparent  that  fundamentally 
and  dramatically  new,  more  efficient  means  of 
designing,  developing,  and  supporting  software 
will  be  mandatoiy. 

Figure  1  shows  the  historical  increase  in  on¬ 
board  programmable  memory  and  processor 
speed  in  military  aircraft.  Signal  processing 
requirements  for  next-generation  fighter  aircraft 
will  reach  approximately  10-20  billion  operations 
per  second  (BOPS)  with  a  need  for  100-200 
MBytes  of  memory  (Ref  1).  Obviously,  when  the 
aforementioned  sensor  processing  and  automation 
processing  capabilities  are  considered,  even  more 
dramatic  spe^s  (e.g.,  10(X)  BOPS)  are  expected 
soon  after  the  turn  of  the  century. 

Figure  2  shows  how  the  cost  of  software 
required  to  fill  Air  Force  needs  is  steadily  growing 
(Ref  2).  For  a  modem  fighter,  we  can  expect  to 
spend  $1.5B  to  develop  the  code  and  $3-4B  to 
support  it  over  the  weapon’s  life  cycle.  Although 
our  efficiency  in  developing  real-time  software  is 
improving  at  3-4%  per  year,  the  demand  is 


growing  at  about  12%  per  year.  We  are  falling 
behind,  and  the  job  is  becoming  harder. 

Figure  3  shows  the  dramatic  shift  from 
hardware-based  solutions  to  software-based 
solutions  (Ref  3).  Despite  the  immense  costs  and 
manpower  shortfall  brought  on  by  real-time 
avionics  software,  its  ability  to  permit  flexibility 
and  ease  of  growth  to  respond  to  the  threat  still 
remains  a  lower  cost  alternative  to  hardware-based 
solutions. 

Avionics  hardware  costs  have  also  been 
escalating  in  response  to  performance  and  system 
adaptability  needs.  Figure  4  shows  the  historical 
trend  in  avionics  cost  as  a  percentage  of  weapon 
system  flyaway  cost.  It  has  been  estimated  that 
hardware  sparing,  repair,  and  maintenance  costs 
can  be  four  to  five  times  as  much  as  the  flyaway 
cost. 

What  arc  the  prima^  cost,  reliability,  weight, 
power,  and  volume  drivers  for  avionics 
hardware?  Although  the  answer  to  this  question 
cannot  be  obtained  unless  the  exact  configuration 
of  the  aircraft  is  known,  general  trend  information 
is  revealing. 

As  an  example,  it  is  highly  informative  to 
compare  the  relative  cost,  weight,  volume, 
electrical  power,  and  reliability  of  avionics  for  a 
conceptual  multipurpose  (air-to-air  and  air-to- 
ground)  fighter  using  today’s  technology.  Figure 
5  (Ref  4)  shows  the  above  breakdown  for  sensors 
(multifunction  integrated  radar,  EW,  CNI,  FLIR, 
terrain  map),  Integrated  Core  Processing  (ICP) 
(data  and  signal  processing),  along  with  stores 
processing,  vehicle  management  system  (VMS), 
system  mass  memory,  and  displays  and  controls. 

Note  the  sheer  dominance  of  sensors  in  all 
categories.  This  should  not  be  surprising  when 
one  considers  the  function  of  avionics  is  to  sense 
or  recall  stored  information  of  the  entire  outside 
world,  provide  information  for  presentation  to  the 
aiicrew,  and  provide  information  to  the  stores  and 
vehicle  control  systems.  It  is  precisely  this 
outside  world,  requiring  improved  sensing,  which 
has  become  so  extremely  complex  and  difficult 
(e.g.,  numerical  superiority  of  threats,  stealth, 
robust  electronic  intelligence,  desire  for 
cooperativefintemetted  operation  with  friendlies, 
the  desire  to  operate  in  adverse  weather  and  at  low 
altitudes,  etc.).  Data  and  signal  processor 
hardware  and  software,  controls/displays,  and 
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avionic  architectures  simply  “operate”  on  the 
fundamental  sensor  data,  reformatting,  storing, 
transporting,  processing,  and  displaying  it.  And, 
potentially  compounding  the  sensor  cost  and 
complexity  situation  around  the  turn  of  the  century 
will  be  the  onset  of  advanced  sensors  and 
algorithms  with  dramatic  new  capabilities. 
Interflight  data  will  be  exchanged  automatically 
with  regularity:  bistatic  radar  operation,  where  the 
emitter  is  in  a  sanctuary  location,  will  become  a 
commonplace  tactic;  ground  targets  will  be 
automatically  recognized,  using  on-board 
Synthetic  Aperture  Radar,  laser  radar  (LADAR), 
and  FLIR.  Some  sensor  components  will  be 
housed  on  Unmanned  Aerial  Vehicles  having 
offensive  and  defensive  missions. 

Sensor  cost  will  be  the  fundamental  driver  in 
determining  what  performance  capability  we  will 
achieve  (afford)  in  the  early  21st  centuiy  for 
military  aircraft.  It  must  be  driven  down;  and 
associated  sensor  weight,  volume,  and  electrical 
power  must  be  controlled.  The  same  concepts  of 
commonality,  modularity,  standardization,  and 
sharing  that  have  dramatically  reduced  the  cost- 
per-performance  ratio  for  the  ICP  portion  of  the 
avionics  system  must  be  applied  to  the  sensor 
portion.  Solutions  are  on  the  horizon.  Both  radio 
frequency  (RF)  and  electro-optical  (EO)  apertures 
can  be  shared  if  the  results  of  current  day  research 
and  development  (R&D)  programs  are  exploited 
(e.g.,  radar/ESM/CNI,  FLIRTIRST);  a  common, 
modular  family  of  supercomputer  quality 
preprocessors  and  signal  processors  is  becoming 
a  reality,  modular  RF  receivers  appear  promising, 
work  on  a  sensor  network  architecture  that 
enables  the  switching  and  data  distribution  of 
sensor  data  has  begun,  and  design  efforts  for 
integrated  sensor  systems  are  underway.  As 
shown  in  Figure  4,  the  steadily  growing  (almost 
straight  line)  percentage  flyaway  cost  of  avionics 
for  fighter  aircraft  (12%  for  the  F-4  in  1960  to 
about  35%  for  new  fighter  aircraft)  must  be 
halted.  Integrated  sensor  systems,  to  be  described 
later,  hold  out  the  greatest  promise  of  stabilizing 
this  trend,  assuming  software  cost  trends  can  be 
also  stabilized. 

The  Need  for  Improved  Avionics  Availability 

The  projected  suppon  environment  for  Air 
Force  avionics  around  the  year  2000  will  force 
fundamental  changes  in  electronics  design, 
packaging,  and  cooling.  The  “Air  Force 
Reliability  and  Maintainability  (R&M)  2000” 


report  portrays  an  immensely  challenging  situation 
for  the  avionics  support  community  (Ref  5).  The 
report  emphasizes  the  need  to  plan  for  austere 
support  conditions,  dramatically  improve  avionics 
reliability,  simplify  maintainability,  and  reduce 
flight-line  personnel,  thereby  reducing 
dependencies  on  the  supply  pipeline. 

The  authors  believe  that  the  “R&M  2()(X)” 
scenario  implies  that  the  following  characteristics 
arc  needed  for  21st  century  avionics:  (1)  we  must 
extend  the  use  of  modular  electronics  across  a 
wide  spectrum  of  avionics  applications;  (2)  the 
number  of  different  module  types  must  be  kept  to 
a  minimum  to  allow  a  full  complement  of  spares 
to  be  carried  on  a  small  ground-based  vehicle;  (3) 
pervasive  use  of  built  in  test/system  integrated  test 
with  AI  programs  is  needed,  iong  with  more 
extensive  use  of  fault  tolerance;  (4)  the  concept  of 
deferred  or  scheduled  maintenance  for  avionics 
will  need  to  be  implemented,  where  graceful 
degradation  concepts  are  built  into  virtually  every 
m^ule;  and  (5)  advanced  packaging  and  cooling 
technologies  must  be  implemental  to  improve 
reliability. 

The  High  Reliability  Fighter  (HRF)  Concept 
Investigation  undertaken  by  ASD/XR  describes 
the  reliability  levels  we  may  be  able  to  achieve  at 
the  start  ofthe  21st  century.  This  study 
developed  a  baseline  airertft  for  comparison 
purposes  consisting  of  the  composite  of  50  nr  so 
of  the  most  reliable  subsystems  in  the  inventory 
(4.35  hours  mean  time  between  failure  [MTBI^ 
for  the  entire  weapon  system).  By  applying  the 
reliability  enhancements  projected  in  airframes, 
engines,  and  avionics,  the  HRF  was  projected  as 
having  a  40  hour  serial  MTBF,  with  the  avionics 
system  MTBF  at  around  186  hours  (compared 
with  12.6  hours  baseline  composite).  By  using 
redundancy,  mean  time  between  critical  failure 
(MTBCF)  figures  of  150  hours  were  projected  for 
the  weapon  system  (Ref  6). 

ClifllleDge 

The  preceding  discussions  highlight  the 
formidable  challenge  of  simultaneously  improving 
performance,  lowering  cost,  and  improving  the 
availability  of  future  military  avionics.  The 
remainder  of  the  paper  offers  projected  solutions 
in  three  broad  areas;  (1)  avionics  architecture, 
including  the  technology  enabling  “infrastructure” 
of  processing,  packaging  and  cooling,  networks 
and  switching  circuitry,  and  the  concept  of 
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integrated  sensor  systems;  (2)  avionics  software; 
and  (3)  avionics  design  environments. 

2.  AVIONICS  ARCHITECTURE 

Trends 

Figure  6  shows  a  portrayal  of  the  federated 
architecture  being  flown  in  a  vast  majority  of 
today’s  U.S.  military  aircraft.  Sensors, 
processors,  and  displays  are  usually  stand-alone 
“black  box  entities.”  Physical  integration  is 
achieved  by  .STANAG  3838  (MIL  STD  1553B) 
data  busfsesj,  with  information  integration 
provided  by  the  crew  which  assimulates  and 
interprets  display  information.  Data  processing 
has  been  generally  standardized  (e.g.,  MIL  STD 
17.50A,  16-bit  computers  for  USAF  aircraft),  with 
JOVIAL  (again  for  the  USAF)  being  the  common 
software  language.  Separate  sensors  have  their 
own  chain  of  apertures,  transmitters,  receivers, 
preprocessors,  signal  processors,  and  sometimes, 
displays.  Multifunction  displays  are  frequently 
used.  System  control  is  provided  by  a  close¬ 
coupling  between  crew  (switch  activation)  and  a 
real-time,  centrally  located  operating  system 
resident  in  a  standard  data  processor. 
Reconfiguration  due  to  a  bus  failure  is  employed. 

This  federated  architecture  stems  from 
pioneering  work  accomplished  by  the  Wright 
Laboratory  Avionics  Directorate’s  Digi'al 
Avionics  Information  System  program  and  has 
been  highly  successful.  However,  system 
limitations  arc  being  obser/ed  for  highly  complex 
avionics  suites.  These  limitations  include: 

a.  inadequate  bus  bandwidth  (1  megabit  per 
second  [MBPS]),  resulting  in  several  buses  being 
required; 

b.  lack  of  robustness  in  operating  system 
control  for  complex  subsystems  that  need  bus 
control  to  accomplish  data  servicing; 

c.  highly  limited  fault  tolerance  capability; 

d.  limited  standardization; 

e.  dependence  on  intermediate  shops  at  air 
base  to  ^fect  repairs,  thereby  incurring  added 
hundreds  of  millions  of  dollars  of  cost  over  the 
avionics  life  cycle. 


The  Integrated  Avionics  Architecture  shown  in 
Figure  7  solves  many  of  the  limitations  and  forms 
the  baseline  architecture  as  we  enter  the  21st 
century.  This  architecture  was  developed  by  the 
Wright  Laboratory  Avionics  Directorate  and  is 
being  employed  on  the  Advanced  Tactical  Fighter 
(F-22)  and  the  RAH-66  (LH)  helicopter.  One 
extremely  important  aspect  of  this  architecture  is 
the  appearance  of  integrated  functional 
subsystems-viz.,  the  integration  of  CNI 
functions  and  EW  functions  to  affect  tighter 
control  and  sharing  of  resources,  the  appearance 
of  a  Vehicle  Management  System  (VMS)  (the 
integration  of  flight,  propulsion,  electrical,  and 
utilities  control),  and  an  integrated  stores 
management  system.  With  the  exception  of  high 
bandwidth  sensor  signals,  data  and  control 
information  is  exchanged  over  the  interconnect 
network  under  control  of  core  processing. 

Because  VMS  is  safety-of-flight  critical  and  stores 
are  safety  critical,  each  integrated  functional 
system  has  its  own  control  resources  and  can 
reject  data  received  from  the  interconnect  network. 
In  order  to  accommodate  high  bandwidth  signals 
between  processing  centers  and  the  cockpit  or 
sensors,  a  High  Speed  Data  Bus  (HSDB) 
“Interconnect  Network”  has  been  added  (a  linear 
token  passing  distributed  protocol  operating  over 
a  50  MBPS  fiber  optic  link).  Graphics-based, 
synthesized  displays  provide  improved  situation 
awareness.  Separate  sensors  send  digitized,  high 
data  rate,  preprocessor  signals  (e.g.,  800  MBPS) 
through  point-pint  (see  Data  Net  block  on  Figure 
7)  fiber  optic  links  to  the  “Core  Processing” 
which  includes  both  signal  and  data  processing. 
This  architecture  framework  can  be  described  as 
“open”  in  tliat  it  does  not  preclude  the  use  of  other 
networks  or  configuration  approaches  within  the 
various  functionally  integrate  systems.  For 
example,  STANA(j  3838  can  be  used  within  the 
VMS,  and  MIL  STD  1760  can  be  used  within  the 
stores  system.  And,  although  the  core  processing 
is  implemented  through  a  controlled  family  of 
standard  form,  fit,  and  function  modules  (which 
are  replaceable  at  the  flight  time  with  no 
intermediate  shop  repair  required),  “black  boxes” 
could  be  used  for  the  VMS  system.  Further,  if  a 
network  of  STANAG  3838  (MIL  STD  1553B) 
based  avionics  boxes  were  to  be  used,  the 
designer  simply  uses  a  HSDB/1553B  input/output 
(I/O)  module,  which  is  one  member  of  the 
standard  family  of  digital  modules.  Standard 
modules  include  I/O,  power  supplies,  network 
switching,  sensor  interface,  global  memory,  16 
bit  and  32  bit  data  pixxessing,  and  floating  point 
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pnxessing  for  virtually  any  data  or  signal 
processing  function.  A  limited  number  of  custom 
modules  are  needed  forEW  and  CNI  signal 
processing. 

Referring  to  Figure  8,  we  see  how  the  family 
of  common  modules  are  “mixed  and  matched”  to 
create  processing  clusters  for  signal  and  data 
processing,  along  with  pooled  spares  for 
purposes  of  reconfiguration  in  the  event  of 
module  failure  during  flight.  This  process 
requires  the  extensive  use  of  chip-level  built-in¬ 
test  and  rji  operating  system  capable  of 
reconfiguring  to  a  desired  state.  An  Ada-based 
operating  system  and  application  programs  are 
used.  The  form,  fit,  and  function  of  all  digital  and 
support  modules,  associated  connectors, 
backplane  buses  and  switches,  and  method  of 
cooling  is  governed  by  a  Tri-Service  organization 
called  the  Joint  Integrated  Avionics  Working 
Group  (JIAWG)  to  ensure  high-volume,  low-cost 
module  use  through  force- wide  deployment. 

From  a  family  of  roughly  20  different  modules 
(including  power  supplies  and  input/output 
modules),  virtually  any  signal  of  data  processing 
function  can  be  implemented,  possibly  using  a 
total  of  200-300  modules.  MwJules  are  edge 
cooled  through  a  conduction  heat  exchange  fiom 
the  module  center  plate  and  the  ribs  (top  and 
bottom)  located  in  the  rack.  The  working  fluid  is 
pumped  through  cavities  in  the  rack  to  enable  easy 
flight-line  replacement  A  typical  module  weighs 
about  0.75  kg,  is  approximately  15x15x1.5  cm  in 
dimension,  and  has  an  approximate  reliability  of 
10,000  hrs  MTBF.  Currently,  32  bit  data 
processor  modules  operate  at  20  million 
instructions  per  second  and  a  Floating  Point 
Processing  Element  module  operates  at  125-150 
million  FLOPS  using  Very  Large  Scale 
Integration  technology.  A  module  generating  40- 
50  watts  can  be  cooled  to  around  80  degrees 
junction  temperature.  Intermodule  communication 
is  supported  by  robust  data  network  and  switch 
traffic  across  a  24-28  layer  backplane  (controlled 
by  the  JIAWG  organization).  Figure  9  shows  a 
Common  Signal  Processor.  Overall  network 
control  resides  with  a  Data  Processing  Module 
which  is  connected  to  a  dual  Parallel  Interface  bus 
(baclqjlane  bus,  25  Megawords/sec)  or  to  a 
Testing/Maintenance  backplane  bus  which 
supports  testing  on  a  noninterference  basis.  High 
speed  digitized  sensor  data  enters  the  processing 
complex  through  a  Sen.sor  Interface  m.odule,  is 
routed  through  the  backplane  to  Data  Flow 


Network,  parallel  switch  modules  (32  bit  data 
path,  25  MHz  clock  for  800  megabit/sec),  to 
Global  Memory  modules  for  buffering  and  on  to 
Processing  Element  modules  for  floating  point 
processing. 

Before  departing  this  architecture,  note  that 
Radio  Frequency  (RF)  and  Intermediate 
Frequency  (IF)  modules  for  a  given  function 
(e.g..  CNI)  could  be  placed  within  the  same 
erclosure  (with  backplane  modifications)  if 
desired.  However,  it  is  fundamental  to  note  that 
although  this  architecture  supports  growth, 
redundancy,  reconfigurability,  communications 
security,  and  data  fusion,  it  is  primarily  a 
digitally-based  system.  It  is  the  product  of  the 
most  advanced  technology  deployable  this  decade. 

21st  Century  Avionics  Architecture 

The  question  can  now  be  asked ...  “how  can 
w-e  improve  on  this  architecmre?”  The  previous 
discussion  on  challenges  for  21st  century  avionics 
reveals  that,  if  possible,  sensor  cost,  weight, 
volume,  and  power  need  to  be  attacked,  further 
reliability  improvements  need  to  be  made,  and  a 
feasible,  cost-effective  means  of  achieving 
“supercomputer”  quality  digital  processing  must 
be  implemented.  We  will  need  to  enhance  the 
baseline  digital  integrated  avionics  architecture 
while  extending  it  into  the  sensors.  The  strategy 
remains  the  same:  continue  with  the  use  of  a 
common,  modular,  standard  family  of  modules 
(be  they  RF  or  digital)  to  reduce  cost  and 
supportability  problems;  share  functions  wherever 
possible  to  reduce  weight,  volume,  and,  hence, 
cost;  exploit  and  integrate  advanced  packaging, 
cooling,  and  interconnect  technologies  to  reduce 
weight  and  volume  and  improve  reliability; 
establish  a  means  to  achieve  fault  tolerant  system 
operation  to  reduce  weight,  volume,  electrical 
power  and  cost,  and  improve  system  availability. 
An  integrated  sensor  architecture  is  needed. 

The  above  question  now  becomes  a  series  of 
questions ...  “^at  do  we  need  to  improve?  With 
what  technologies?  What  are  the  needed 
architectural  constructs?  Can  we  simply  add  on  to 
the  PAVE  PILLAR  architecture  or  must  we 
substantially  depart  from  it?  Are  there 
evolutionary  steps  which  must  be  taken?  Are  we 
clever  enough  to  overcome  software  complexity 
problems?  Will  cultural  resistance  to  functional 
integration  be  a  more  powerful  retadaiit  dian  the 
technology?  How  does  a  design  team  architect 


such  a  system?  What  will  happen  to  classical 
boundaries  between  CNI,  radar,  or  EW;  to 
offensive  and  defensive  avionics;  to  RF  and  EO 
avionics?”  The  following  discussion  hopefully 
will  provide  insight  into  these  issues. 

Figure  10  outlines  the  basic  requirements  that 
must  be  embodied  in  this  advanced  architecture. 
The  PAVE  PACE  program,  currently  underway  at 
Wright  Laboratory,  has  begun  the  process  to 
embody  these  requirements  initially  into  a  design 
and  ultimately,  into  a  system  demonstration. 
Figure  1 1  shows  the  resulting  top-level  system 
block  diagram  and  the  highlights  of  the  approach 
being  taken.  Note  the  fundamental  precept  of 
bulling  onto  the  PAVE  PILLAR  concept  to 
permit  cost  effective  preplanned  product 
improvement  upgrades  as  well  as  application  to 
new  aircraft  weapon  systems.  In  comparing  this 
architecture  with  Figure  7  (PAVE  PILLAR),  the 
most  obvious  difference  is  the  introduction  of  the 
integrated  RF  and  EO  sensor  systems.  As  we  will 
see,  there  will  also  be  significant  upgrades  to  the 
data  network  and  the  core  processing.  Note  also 
that  future  avionics  systems  can  be  viewed  as 
consisting  of  six  major  categories:  RF,  EO,  core 
processing,  cockpit,  vehicle  management 
processing  (flight,  propulsion,  and  utility 
control),  and  stores  processing.  The  following 
discussion  outlines  the  basic  characteristics  of  this 
21st  century  architecture. 

Intea-ated  Core  Processing 

The  Integrated  Core  Processing  functional  area 
accomplishes  signal,  data,  and  a  majority  of 
digital  preprocessing  functions  using  a  standard 
family  of  highly  advanced  digital  modules. 

During  2000-2010  application,  it  is  predicted 
that  silicon-based  digital  circuits  (e.g.,  BICMOS) 
will  still  be  the  dominant  technology,  with  circuit 
feature  size  of  0.5  microns  and  a  clock  rate  of 
100-150  MHz  being  commonly  used.  Multi-chip 
packaging  (MCP)  will  be  required  to  avoid  the 
speed  slowdown  encountered  by  printed  wiring 
boards  (e.g.,  a  factor  of  4  speedup  is  possible). 
Here,  bare  chips  will  be  closely  array^  on  silicon 
substrates,  with  interchip  communication 
accomplished  by  balanced  transmission  lines  a 
few  microns  wide.  Wafer  scale  integration  and 
superconductivity  are  not  currently  projected  to  be 
used  except  for  highly  specialized  applications.  It 
is  project^  that  by  a  1998  proven  technology 
availability  date,  the  following  performance 


should  be  achieved  per  module:  General  Purpose 
Processing  Element:  450  MIPS;  Floating  Point 
Processing  Element:  2400  MFLOPS;  System 
Mass  Memory:  144  Mbytes;  Photonic  Switch 
Module;  64  x  64  optical  cross-bar  switch. 

MCPs  will  form  the  building  block  for  future 
digital  avionics.  An  MCP  can  be  imagined  to 
contain  40-50  chips,  is  5  times  more  efficient  in 
packaging  density,  consumes  5-50  watts, 
measures  2.5  to  10  cm  on  a  side,  and  has  a 
reliability  in  excess  of  100,000  hre  MTBF.  They 
are  a  possible  throwaway  item  at  the  depot. 

Figure  12  shows  the  concept  of  how  members 
of  a  MCP  family  are  “mixed  and  matched”  to 
create  a  family  of  standard  modules.  Such  a 
module  is  shown  in  Figure  13.  Note  that  because 
of  extremely  dense  MCP  packaging  and  high 
circuit  clock  rate,  modules  will  require  improved 
cooling  since  100-200  watts  heat  generation  per 
module  is  forecast.  Liquid  flow-tlu'ough  cooling, 
where  the  fluid  in  the  rack  is  pumped  through  a 
heat  exchanger  within  the  hollow  centerplate  of 
the  module,  will  be  used.  This  technology  has 
been  tested  for  ruggedness  and  is  capable  of 
removing  200  watts  with  a  junction  temperature  of 
83®C.  Note,  also  (Figure  13),  that  optical 
interconnects  will  be  commonly  used  to  affect 
sensor/module  and  module/module  data 
interchange.  Such  interconnects  are  needed  to 
permit  high  speed  (2  Gigabit/sec)  switched  data  to 
be  processed,  creating  the  need  for  an  optical 
switching  module,  a  photonic  backplane,  and 
photonic  I/O  circuitry  on  each  module.  Figure  14 
shows  a  conceptual  portrayal  of  how  various 
modules  would  communicate  through  the  switch 
controller.  Such  a  photonic  backplane 
configuration,  operating  at  1  Gigabit/sec  is  being 
developed  by  the  Wright  Laboratory  Avionics 
Directorate.  Substantial  size  reductions  of  the 
laser  transmitter  will  have  to  be  made  before  this 
design  is  implemented  in  practice,  although  it  is 
expected  to  be  available  by  1995. 

Cockpit/Pilot  Vehicle  Interface  (PVI) 

Reduction  of  crew  workload  while  providing 
situation  awareness  of  the  threat,  targets, 
friendlies,  weather  temin,  and  obstacles  will 
remain  the  PVI  challenge  for  early  21st  century 
avionics  designers.  Figure  15  illustrates  an 
advanced  PVI  concept  with  these  capabilities.  An 
inte^led  helmet  mounted  display/sight  will 
provide  a  graphical,  “virtual”  world  for  situation 
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awareness  and  off-boresight  target  acquisition  and 
weapon  release.  Large  head-down  displays, 
using  full  color  liquid  crystal  display  and  robust 
graphics  technologies  will  be  used  to  present 
“BIG  PICTURE”  situation  awareness. 
Information  from  several  sensor  sources,  whether 
on-board,  from  within  the  flight,  or  external  to  the 
flight,  will  be  fused  for  improved  graphical 
imagery  presentation  targeting  or  track  file 
prediction.  Artificial  intelligence  technology  will 
be  used  for  automatic  display  modeling  and  for 
real-time  route  planning,  and  will  provide  crew 
recommendations  for  tactics  and  system 
reconfiguration  in  the  event  of  haidware  failure. 

In  addition,  speech  recognition  is  expected  to  find 
utility  in  this  time  frame.  However,  the  most 
significant  automation  impact  is  expected  to  occur 
with  automatic  target  recognition.  This 
technology  is  being  vigorously  pursued  at  the 
Wright  Laboratory  Avionics  Directorate  and  is 
expected  to  finu  partial  use  before  the  end  of  this 
decade  (e.g.,  target  cueing)  and  be  fully 
operational  by  2005-2010.  The  vast  majority  of 
graphical,  fusion,  and  automation  processing  will 
occur  in  the  integrated  mission  processor 
complex.  Communication  to  the  cockpit  (panel 
and  Helmen: '  lounted  Display)  will  be 
accomplished  over  a  fiber-optic,  switched 
network. 

■Ystiicls.Managgmgai  SiisiemlYMS) 

Early  21st  century  fighter  aircraft  are  expected 
to  utilize  highly  maneuverable  fly-by- wire  flight 
controls,  as  well  as  thrust  vectoring,  all  aimed  at 
achieving  extreme  maneuverability. 

Advanced  VMS  designs  are  expected  to 
incorporate  an  integrated  suite  of  sensors, 
effectors,  and  processors  that  control  the  state  of 
the  vehicle.  This  suite  will  include:  (1)  flight 
control  resources  such  as  control  surfaces;  vehicle 
reference  sensors  such  as  accelerometers,  rate 
gyros,  angle  of  attack,  and  airspeed  indicators;  (2) 
utility  management  functions  such  as  electrical 
power  control,  lighting,  nose  wheel  steering,  and 
environmental  control  system;  (3)  propulsion 
control  (both  engine,  thrust  deflectors,  and  inlet 
control;  (4)  controls  (e.g.,  throttle,  stick,  rudder 
pedals)  and  displays  (e.g.,  attitude  direction 
indicator,  angle  of  attack  indicator)  (see  Figure 
16).  An  integrated,  bus-structured  triply- 
redundant  set  of  vehicle  management  processor 
clusters  will  be  used  to  meet  safety-of-flight  (the 
probability  of  loss  of  control  for  the  vehicle 


should  be  less  than  1x10  ®,  the  probability  of 
mission  abort  less  than  IxlO'^).  Such  a  highly 
fault  tolerant  system  must  detect,  isolate,  and 
recover  from  faults  in  less  than  30  milliseconds. 
Although  a  modular  approach  will  be  used  to 
promote  ease  of  maintenance  and  supportability 
improvements,  the  question  of  the  degree  of 
commonality  with  mission  processing  modules  is 
still  under  investigation.  Although  power  supply 
and  switch  modules  could  be  used,  most 
memories  on  the  VMS  should  be  “bumed-in”  read 
only  memories  (with  battery  backup)  to  protect 
against  electrical  transients.  However,  many  of 
the  previously  described  MCPs  can  be  used. 

Because  the  integrated  data  network  traffic  is 
under  1  Megabii/sec,  debate  continues  on  the  need 
to  use  a  high  speed  data  bus  fo.’-  commonality 
reasons  (50  Mcgabit(sec)  oi  a  DOD  MIL-STT) 

1773  bus  (the  fiber  optic  version  of  STANAG 
3838). 

A  significant  issue  is  the  extent  of  VMS/Core 
Processing  i'  -gration.  It  is  expected  that  shared 
inertial  sensors  (for  flight  conur>l  and  for  inertial 
navigation)  will  become  commonplace  for  cost 
reasons.  Because  of  the  close  weapon  system 
coupling  that  is  occurring  with  the  VMS  in  the 
areas  of  terrain  followin^avoidance,  weapons 
control,  automatic,  air-air  trajectory  control,  and 
the  powerful  new  control  capabilities  that  an 
integrated  VMS  provides  (e.g.,  high  angle  of 
attack  gunnery  during  air-air  combat,  rapid  nose 
pointing),  debate  continues  as  to  whether  system 
control,  trajectory  steering,  display  management, 
stores  control,  etc.  should  reside  on  the  mission 
processing  or  VMS  areas.  The  authors  believe 
that  generic  boundaries  of  mission  processing, 
stores  management,  cockpit,  sensors,  and  VMS 
will  exist  on  early  21st  century  avionics. 

However,  there  will  be  close  information  coupling 
across  a  sy  stem  of  data  networks  contained  within 
each  functional  area.  Safety  (e.g.,  inadvertent 
stores  release)  and  safety-of-flight  (e.g., 
unrecoverable  angle  of  attack)  will  dominate  VMS 
and  stores  system  architecture  partitioning.  Each 
safety-related  functional  area  will  request  data 
services  from  the  integrated  core  processing  area, 
and  will  then  ensure  its  acceptability  before  use. 

Integrated  Sensor  Systems 

Having  briefly  described  the  core  processing, 
cockpit,  and  VMS  systems,  the  integrated  RF  and 
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EO  systems,  projected  to  be  available  in  the  2005- 
2010  time  frame,  will  now  be  discussed. 

The  advent  of  microwave  and  millimeter 
integrated  circuit  (MMIC)  technologies,  opto¬ 
electronics  and  high  speed  digital  circuitry  will 
allow  us  to  re-look  at  the  way  RF  electronics  are 
designed,  developed,  and  integrated.  Several 
questions  come  to  mind:  (1)  are  there  ways  in 
w  hich  we  can  reduce  weight,  volume,  power,  and 
cost  through  functional  sharing  of  hardware 
building  blocks?  (2)  does  it  mice  sense  to  attempt 
to  reuse  these  building  blocks  across  diverse 
weapon  systems?  (3)  what  type  of  .lew  integrating 
architect  ire  is  needed? 

In  a,iswering  liiese  questions,  one  must 
acknowledge  that  RF  systems  differ  greatly  from 
digital  systems  in  the  following,  ft.'idamental 
ways.  RF  systems  are  m.  Iti-dimensional  in 
bandwidth,  dynamic  range,  and  phase  and  as 
such,  they  have  been  implemented  as  point- 
designed,  custom  functions  within  EW,  CNI,  or 
radar  functions.  As  a  result,  one  RF  system 
component  is  often  dependent  on  anotiier  (e.g., 
multi-stage  amplifier  circuits  located  across  the 
sensor  system).  If  we  are  to  separate  unique, 
point  designed  equipment  from  common 
hardware,  we  must  be  able  to  “contain”  unique 
requirements  closer  to  the  aperture  and  develop  a 
“standard  I/O”  interface  that  will  allow  common 
modules  to  be  used.  RF  equipment,  because  of 
its  uniqueness,  has  not  enjoy^  the 
“infrastructure”  of  the  digital  industry  relative  to 
common  manufacturing  techniques,  chips,  etc. 
The  RF  industry  often  has  to  “roll  their  own”, 
building  onto  what  worked  before.  As  a  result, 
learning  curve  experience  and  reliability  is  difficult 
to  achieve  with  low  volume  production  and  high 
non-iecurring  expenses. 

Based  on  the  above  considerations,  it  would 
appear  that  commonly  shared  receiver  modules 
may  be  the  most  attractive  area  for  RF 
standardization.  For  example,  EW  receiver 
modules,  each  responsible  for  a  specific 
frequency  band,  could  be  time  shared  across 
various  EW  apertures  on  an  aircraft  (the  radar 
receiver  function  may  be  a  candidate  for  sharing 
under  specific  conditions).  Similarly,  CNI 
receiver  modules  can  be  time  shared  across  the 
20MHz-2GHz  spectrum.  These  modules  would 
hopefully  find  standardized  use  across  various 
aircraft  types. 


Using  such  receiver  modules  in  such  a  manner 
inquiies  a  very  low  noise  network  that  switches 
the  intermediate  frequency  signal  to  the 
appropriate  rcceivers/processor  modules. 

Further,  this  switched  network  must  support 
multifunction  apertures  which  ate  expect^  to  be 
available  by  the  21st  century. 

RF  modules  will  fall  into  two  classes:  a  set 
which  can  be  shared/duplicated  across  functions 
within  and  across  aircraft,  and  a  set  that  is  unique 
to  a  sensor  function,  but  which  can  be  used  on 
several  other  aircraft  types. 

The  type  of  “sensor  architectme”  needed  will 
be  determined  by  several  factors.  For  example, 
we  will  need  to  determine  the  extent  of  modularity 
and  fault  tolerance  needed  to  achieve  improved 
availability,  where  digital  signal  conversion  is  best 
accomplished,  where  advanced  signal  fusion 
should  best  occur  and  the  degree  to  which 
multifunction  apertures  will  be  available.  These 
issues  are,  in  turn,  related  to  hardware  “front-end” 
and  receiver  technology  availability  and  the 
resulting  complexity  and  amount  of  the  software 
needed  to  control  the  system. 

Figure  17  shows  the  basic  concept  behind  an 
integrated  RF  system  design.  First,  note  the  use 
of  shared  RF  apertures  across  classical  RF 
functions.  A  recent  PAVE  PACE  study 
accomplished  by  McDonnell  Douglas  Corporation 
estimated  that  a  total  of  13  antennas  (five  basic 
types)  will  provide  all  the  CNl/EW/r^ar 
functions,  replacing  25-35  different  antennas 
normally  found  on  tactical  aircraft.  Here  it  is 
assumed  the  RF  band  of  operation  extends  from 
30  MHz  to  18000  MHz,  with  growth  provisions 
for  higher  frequencies.  Both  multi-arm  and  active 
phased  array  antennas  will  be  used.  Broadband 
matrix  switches,  beamforming  networks,  and 
built-in-test  circuitry  will  be  used  in  the  aperture 
electronics,  along  with  MMIC  technolo^  used 
for  phase  shifters,  switches,  and  low  noise 
amplifiers. 

Studies  to  date  indicate  that  only  four  frequency 
converter  types,  each  implemented  in  standard 
flow-through  modules,  are  needed  to  cover  the 
entire  RF  band  (see  Figure  18).  The  output  of 
each  converter  is  a  standard  IF  frequency  where  a 
common  IF  switch  module  is  used  to  direct  the 
signals  to  various  standard  receiver  modules  (six 
types  needed).  In  this  way,  various  shared 
apertures  can  be  switched  to  frequency  converters 
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(RF  interconnect),  and  frequency  converter 
modules  can  be  switched  to  various  receiver 
modules  (common  IF  switch),  a  fault  tolerant, 
shared  family  of  resources  will  be  employed  to 
dramatically  reduce  cost,  weight,  and  volume. 

For  the  entire  integrated  RF  design,  a  total  of 
approximately  105  standard  modules,  21  of  which 
are  common  to  core  processing,  will  be  needed 
(see  Figure  19). 

Few  opponunities  for  sharing  EO  sensors 
appear  to  exist  relative  to  the  RF  domain. 
However,  significant  cost  savings  will  occur  if  a 
common  IRST/FLIR  apermre  is  used,  along  with 
common  modular  preprocessors  and  integrated 
core  processing.  Figure  20  shows  a  general 
configuration  of  such  an  integrated  EO  system. 

PAVE  PAGE  studies  to  date  reveal  that 
significant  weight,  volume,  and  cost  savings  can 
be  achieved  by  the  use  of  common,  modular 
avionics  in  both  RF  and  EO  sensors,  along  with 
the  sharing  of  aperture  and  receiver  electronics. 
Prelimin.'ry  analysis  shows  that  for  the  RF 
system,  65%  of  the  acquisition  cost  can  be  saved 
by  the  use  of  standard  modules  alone,  compared 
with  a  non-integrated,  non-modular  RF  design. 

The  table  below  summanzes  the  results  of  the 
McDonnell  Douglas  PAVE  PACE  study. 


IfmCRATED  RFSySTEM’ 

FEDERATED  RF> 

(1998  TECHNOLOGY 

(CURRENT  R&D 

AVAILAEIUTY) 

TECHNOLOCY) 

REUAPIUTY  (HOURS) 

441 

158 

COST  (1990.  U.S  DOLLARS) 

18M 

7.2M 

POWER  (KILOWATTS) 

31 

35 

WHGHT(LBS) 

,  450 

940 

VOLUME  (FT^) 

5.4 

11  5 

INTEGRATED  EO  SYSTEM^ 

FEDERATED  EO  SYSTEM^ 

REUABIUTY  (HOURS) 

424 

92 

COST  (1990,  U.S.  DOLLARS) 

19M 

4.dM 

POWER  (KILOWATTS) 

4 

7.6 

WEIGHT  (LBS) 

540 

854 

VOLUME  (FT^) 

6.5 

18  1 

1  RF  sysiem  consists  of  full  function  CNI,  multifunction 
radar,  and  ^^SM/clcctronic  counicmicasure  (ECM)  system. 

2,  EO  sysiem  consists  of  Navigation  FLIR,  targeting  FLIR. 
IRST,  infrared  missile  warning  (IRMW),  laser  warning,  laser 
illuminator. 

Figure  21  shows  the  significant  differences 
between  the  use  of  federated  and  integrated 
sensors  for  fighter  aircraft  of  the  early  21st 


century.  One  observation  is  clear;  inte^ated 
sensor  systems  implemented  with  a  family  of 
modules  wiU  be  the  most  dominant  change  in 
avionics  during  this  period. 

3.  21  .ST  CENTURY  AVIONICS  SOFTWARE 

FimctioiiaLPartitipnine 

Figure  22  shows  the  six  principal  application 
centers  that  constimte  the  software  architecture  for 
future  tactical  aircraft.  Each  functional  block 
shown  has  been  defined  to:  reduce  duplicative 
functions,  enable  a  modular  software  framework, 
reduce  data  latencies,  allow  for  growth,  and 
enable  flight  safety  and  system  security  related 
functions  to  be  segregated  from  the  rest  of  the 
•vstem.  Note  that  a  complex,  intemetted  set  of 
smaller  software  modules  exists  within  each 
“major”  module  shown. 

The  Integrated  Core  Processing  “meta¬ 
function”  is  partitioned  into  a  set  of  artificial 
intelligence-based  software  modules  that  enables 
mission  planning,  ■'.ctical  planning,  situation 
assessment,  and  P  .,  reflecting  the  need  to  assist 
the  pilot  in  compi.x,  time-compressed  missions. 
Further,  an  integrated  data  base  is  postulated.  It 
permits  a  coherent  integration  of  previously 
federated  data  bases  dealing  with  knowledge 
bases,  electronic  combat,  weapons  data, 
maintenance  data,  terrain,  navigation  waypoints, 
etc.  This  approach  will  bring  much  needed 
discipline  and  commonality  to  an  area  which  has 
seen  tremendous  proliferation. 

Figure  22  also  shows  a  more  fundamental 
change  in  avionics  tliat  is  expected;  viz.,  the 
classical  partitioning  of  sensors  into  offensive  and 
defensive  categories  has  disappeared.  One  can  no 
longer  find  top-level  “radar”  or  “CNI”  modules, 
but  rather,  an  “Integrated  RF  module”.  A  new 
culture  will  be  needed;  new  ways  to  organize,  to 
design,  to  communicate  are  needed.  Designers 
must  become  more  function  oriented,  instead  of 
sensor  oriented.  For  example,  the  range  and 
angle  to  target  functions  classically  provided  by 
radar,  ESM,  and  IRST  are  now  viewed  as  coming 
from  an  RF  and  an  EO  system. 

Figure  22  also  shows  the  estimated  magnitude 
of  the  flow  of  digitized  data  between  functional 
modules.  Figure  23  shows  a  general 
configuration  of  iiow  digitized  sensor  data,  data 
flowing  between  data  and  signal  processors,  and 
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digitized  video  data  is  routed  through  very  high 
speed  optical  network  switches.  Most  of  these 
identical  switches  will  be  dual  redundant  for  fault 
tolerance. 

This  network  will  consist  of  an  optical  cross¬ 
bar  switch  of  approximately  64x64  size  and  will 
operate  as  serid  links  around  2.5  Gigabits  per 
second,  and  packaged  within  a  stanctod  line 
replaceable  module.  Note  that  this  network  is  also 
used  to  distribute  data  across  a  photonic  backplane 
that  houses  the  array  of  standard  modules 
performing  pre-processing,  signal,  and  data 
processing.  With  the  advent  of  high  speed, 
compact  photonics  packaging,  it  is  expected  that 
the  use  of  metal  cucuits  to  carry  signals  between 
subsystems  and  across  backplanes  will  be 
replaced  by  photonic  circuits  built  from  fiber  cable 
and  optical  waveguides.  Also,  the  future  of  most 
bus-oriented  circuitry  (photonic  or  not)  appears  to 
be  limited  because  of  the  significant  strides 
projected  for  semiconductor-based  optical 
switches  (i.e.,  complex  protocols  and  bottlenecks 
occurring  with  buses  are  avoided  with  switched 
networks). 

Software  -  The  Future  is  Uncertain 

The  above  discussion  assumes  that  needed  real¬ 
time  software  can  be,  and  will  be,  developed  to 
suppon  the  early  21st  century  avionics  systems. 
Figures  1, 2,  and  3  clearly  showed  the  magnitude 
of  software  growth  through  the  1990s.  It  is 
expected  that  this  growth  will  only  escalate  during 
the  early  21st  century. 

Currently,  rhe  U.S.  Department  of  Defense, 
which  went  from  a  $20  billion  software 
expenditure  during  1988  to  a  $34  billion 
expenditure  in  1990,  has  more  lines  of  software 
code  on  order  in  1990  than  has  been  written  for 
existing  systems  (Ref  7).  Software  development 
programs,  whether  military,  commercial,  or 
consumer  based  are  rarely  on  time  and  within 
budget.  1  iiere  is  a  substantial  shortfall  of  trained 
software  pi;rsonnel  (a  12%  demand  growth  versus 
a  4%  ^"pply  growth  per  year).  Wc  make  the  vast 
percentage  of  mistakes  during  the  conceptual 
design  stage.  For  avionics,  a  million  lines  of  code 
requiring  hundreds  of  people  working  for  3-5 
years,  must  nin  in  real  time,  and  is  expected  to 
contain  zero  errors.  And  then  twice  that  cost  and 
effort  will  be  spent  debugging,  changing,  and 
upgrading  that  software  over  the  life  cycle  of  the 
weapon  system.  Clearly,  a  crisis  condition  exists 


in  the  design,  development,  and  support  of 
software.  These  problems  are  further 
compounded  when  the  avionics  requirements  of 
real-time  operation  and  flight  criticality  are  added. 
We  are  currently  approaching  a  cross  road  where 
the  question  must  be  asked ...  “are  we  capable  of 
designing  the  software  needed  to  implement  the 
integration  concepts  enabled  by  advanced 
hardware?  Can  we  afford  the  software?” 

A  significant  effort  is  underway  to  “solve”  the 
“software  problem”.  Fundamentally,  it  must  be 
mmed  into  an  engineering  discipline  raiher  than  a 
“black  art”.  New  tools  and  procedures  will  be 
required;  a  new  development  and  support  piocess 
is  needed. 

The  software  process  has  often  been  divided 
into  several  life  cycle  phases  as  evidenced  by 
many  life  cycle  models.  These  phases  often 
include  requirements  analysis,  specification, 
design,  code,  test,  integration,  deployment,  and 
post-deployment  support.  Of  these  phases,  post¬ 
deployment  support  or  maintenance  makes  up 
over  66%  of  the  cost  of  the  software.  Therefore, 
it  has  often  been  addressed  separately.  However, 
this  post-deployment  support  is  finally  being 
recognized  as  simply  an  extension  of  the 
development  cycle.  Many  have  recognized  that 
the  current  waterfall  life  cycle  of  DoD  STD  2167 A 
(Figure  24)  is  in  fact  insufficient  to  address 
complex  software  systems.  Each  phase  of  the  life 
cycle  cannot  be  completely  determined  before 
beginning  the  next  phase.  This  approach 
inu-oduces  a  paradox:  one  cannot  really 
understand  the  problem  until  the  software  is 
complete;  however,  you  cannot  write  the  software 
until  you  understand  the  problem.  This  is  the 
reason  many  experts  in  the  field  are  beginning  to 
suggest  a  spiral  or  cyclic  life  cycle  model  'Eigure 
25).  This  model  consists  of  specify  a  little, 
design  a  little,  code  a  little,  test  a  little,  and  repeat. 
This  method  is  also  known  as  prototyping.  The 
process  is  repeated  until  the  desired  detail  and 
functionality  is  obtained.  In  this  way  of  thinking, 
post-deployment  support  is  only  another  set  of 
cycles  of  the  basic  development  cycle.  The 
emphasis  on  software  management  for  future 
avionics  systems  should  center  around  improving 
this  basic  development  cycle  (Ref  2). 

The  keystone  to  improving  productivity  and 
quality  of  software  is  software  reuse  in  the  most 
general  sense.  .Software  reuse  relates  to  not 
reinventing  the  wheel  at  each  step  in  the  software 
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life  cycle.  Reuse  strikes  at  the  heart  of  the  “not 
invented  here”  syndrome.  The  reuse  concept  has 
been  used  within  computer  science  for  decades. 
The  concept  is  simple.  Wiien  faced  with  more 
and  more  lines  of  code  to  write,  one  simply 
abstracts  the  language  one  uses  so  that  fewer  lines 
of  code  need  to  he  wntten.  This  can  be  seen  in 
the  development  of  higher  order  languages  (HOL) 
in  the  late  1960s  and  1970s.  Faced  with  writing 
massive  amounts  of  assembly  code,  computer 
scientists  came  up  with  a  higher  level  of 
abstraction  in  HOL  such  as  FORTRAN  to  reduce 
the  amount  of  code  needed  to  be  written  Then 
with  the  development  of  very  efficient  compilers, 
HOL  programmers  were  able  to  write  one  line  of 
HOL  code  tliat  was  translated  into  several  lines  of 
assembly  language.  This  same  principle  was  used 
in  the  development  of  fourth-generation  languages 
in  the  business  community.  Another  form  of 
reuse  has  existed  for  years.  In  the  scientific  and 
mathematical  community,  mathematical  and 
statistical  packages  have  been  extensively  reused 
successfully  for  years.  The  challenge  then  is  to 
develop  a  strategy  for  injecting  reuse  into  the  real¬ 
time  avionics  software  development  environment 
to  reduce  the  cost  of  avionics  software  through 
increased  productivity  and  improved  quality. 

Unfortunately,  the  solution  to  increasing  the 
amount  of  reuse  only  partially  requires  a  technical 
solution.  The  other  portion  of  the  solution 
involves  changes  in  culture,  management,  and 
acquisition  practices.  Both  the  technical  and  non¬ 
technical  issues  have  been  spelled  out  in 
numerous  reports.  The  real  solution  will  involve 
bringing  technical  solutions  from  other  domains  to 
bear  while  considering  the  unique  features  of 
avionics,  and  experimenting  with  innovative 
acquisition  and  management  practices. 

The  technical  solution  has  to  involve  a 
coordinated  attack  along  several  fronts.  First, 
reuse  has  to  be  embedded  in  the  software  practices 
and  methods  along  the  entire  liie  cycle.  TTiis 
includes  introduction  of  reuse  into  specification 
and  design  as  well  as  code  and  test.  To  do  this, 
the  tools  and  methods  in  a  software  environment 
have  to  be  able  to  support  reuse.  Second,  a  level 
of  abstraction  appropriate  to  avionics  or  other 
subdomains  within  avionics  needs  to  be  agreed 
upon.  This  will  enable  the  level  and  types  of 
reuse  to  be  defined  and  allow  languages  to  be 
defined  to  capture  this  reuse.  This  will  then  allow 
“compilers”  or  translators  to  be  developed  to  make 
the  proper  transformations.  Note  that  this  does 


not  mean  the  elimination  of  the  Ada  standard 
anymore  than  the  introduction  of  FORTRAN 
spelled  the  end  of  assembly  language.  These 
higher  level  avionics  language  abstractions  will  be 
built  on  Ada.  Third,  a  method  to  catalog  and 
retrieve  the  reusable  components  needs  to  be 
implemented.  This  methodology  requires  the  mix 
of  database  techniques,  artificial  intelligence,  and 
software  engineering  principles.  And  finally,  this 
whole  process  must  be  instrumented  to  measure 
not  only  the  productivity,  but  to  improve  the 
quality  and  confidence  in  reused  components. 
Metrics  can  be  developed  to  track  the  quality  of 
reused  components  to  give  the  designer  some 
confidence  in  the  quality  of  the  component.  Also, 
reusable  components  could  make  formal 
verification  with  correctness  proofs  a  viable 
alternative.  Proofs  could  be  performed  on 
reusable  components  once  and  then  reused  with 
complete  assurance  over  and  over. 

The  management  and  acquisition  issues 
associated  with  software  reuse  will  probably  be 
more  difficult  to  tackle  than  the  technical  issues 
involved.  A  change  in  culture  will  have  to  occur 
within  the  software  development  community.  The 
“not  invented  here”  syndrome  will  have  to  be 
overcome.  Acquisition  practices  will  need  to 
change  to  create  incentives  for  software  reuse. 
Software  reuse  involves  a  heavy  up-ffont 
investment  to  save  cost  later  in  the  life  cycle  and  in 
other  related  projects.  This  investment  cannot  be 
justified  in  today’s  acquisition  environment  of 
cost-plus  or  fixed  fee  contracts.  The  idea  of 
royalties  m.ay  need  to  be  investigated  for  reusable 
components.  This  will  promote  the  development 
of  quality  reusable  components,  since  developers 
wi’l  get  paid  based  on  the  number  of  times  a 
component  gets  reused.  And  finally,  the  legal 
issues  of  responsibility  need  to  be  addressed. 

This  could  perhaps  be  the  greatest  difficulty  in 
reusing  components  across  the  avionics  industry. 

Once  a  software  development  process  is 
established,  an  integrated  set  of  Computer 
Automated  Software  Engineering  (CASE)  tools 
will  be  needed.  The  following  discussion  of 
CASE  tools  is  adapted  from  Hairis  and  Jackson 
(Ref  8). 

Avjanics  CASE  Tools 

Of  the  more  than  200  CASE  tool  vendors 
today,  most  have  focused  on  only  a  small  portion 
of  the  total  system  development  process  as 
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mandated  by  MIL-STD-2167A.  Most  tools  stress 
requirements  analysis  and  design  specifications. 

In  general,  each  tool  has  its  own  data  base  and 
internal  interfaces  that  are  usually  incompatible 
with  other  tools. 

There  is  a  need  to  emphasize  those  tools 
necessary  to  maintain  software  throughout  its 
lifetime,  plus  tools  critical  to  avionics  software 
development.  Table  1  lists  representative  CASE 
tools  that  need  to  be  integrated. 

TOOLS  THAT  ARE  NEEDED 

•  Requirements 

•  Rapid  Prototyping 

•  Analysis/Trade-Offs/ 

Conflicts 

•  Tracing 

•  Design 

•  Structurcd/Objcct 
Oriented 

•  Selection  of  Reusable 
Components 

•  Analysis/Impaci 

•  Reverse«Engmecnng 

•Code 

•  Semi-Automatic  from 
Design 

•  Smart  Editor 

•  Initial  Test 
« Automated  Test  Case 

Generauon 

•  Automated  UmtTesi 

•  Automated  CSCI  Test 

•  Test  Analysis 

Table  1.  Representative  CASE  Tools  That 
Need  to  be  Integrated 

Avionics  software  and  hardware  are  often 
developed  concurrendy.  MrL-STD-2167A  even 
assumes  this  concurrency.  Consequently,  there  is 
a  need  for  tools  that  permit  integrated  system 
modeling  (hardware  and  software).  Some  CASE 
vendors  have  recognized  this  by  teaming  with 
hardware  simulation  vendors  to  produce  this  joint 
capability.  This,  however,  is  not  typical. 

As  a  complement  to  hardware  development, 
traditional  software  engineering  is  based  on  top- 
down,  functional  decomposition  of  software 
requirements  in  order  to  arrive  at  computer 
software  configuration  units.  These  units 
represent  testable  code.  More  recent  software 
design  methodologies,  however,  are  embracing 


concepts  of  software  reusability  and  adaptability 
for  their  products.  CASE  has  not  yet  addressed 
this  latter  approach. 

As  technologies  advance  and  integrated 
avionics  become  a  reality,  there  is  a  need  for  tools 
that  permit  development  plus  lifetime  support  of 
new  architectures  that  implement  integrate 
systems.  These  tools  should  cover  both  initial 
and  post-development  cycles,  and  support  both 
hardware  and  software  simulations. 

There  is  a  need  for  CASE  to  provide 
“instantaneous”  documentation  methods.  Using 
multi-media  technologies,  it  should  be  possible 
for  documentation  to  be  a  natural  part  of  the 
design  process,  rather  than  an  appendage  that 
occurs  near  the  end  of  a  milestone. 

Tools  that  provide  “automatic”  code  generation 
and  that  draw  from  reusable  software  libraries  are 
needed  for  large  software-intensive  programs. 
Many  current  tools  make  claims  for  code 
generation,  however,  in  most  cases,  only  the 
“shell”  for  code  structure  is  provided.  While  this 
is  a  step  towards  automatic  coding,  the  ultimate 
CASE  tool  would  produce  compilable  code  based 
on  an  object-oriented  design  methodology. 

Most  methodologies  implemented  by  CASE 
tools  supporting  Ada  define  only  high-level 
declarations  for  the  language,  and  lack  capabilities 
that  define  package  specifications,  package 
bodies,  generic  units,  and  limited  private  types. 

CASE  tools  should  support  planners, 
managers,  analysts,  designers,  engineers, 
programmers,  and  system  maintainers.  There  is 
no  current  comprehensive  tool  that  serves  all  of 
these  masters,  although  some  purport  to.  The 
problem  collectively  for  CASE  is  that  titere  are  no 
standards  for  interfacing  tools  or  data  bases,  so 
that  individual  tools  effectively  and  efficiently 
complement  one  another.  This  has  forced 
nonuniformity  in  software  engineering 
environments  and  the  products  they  produced. 

An  Implementation  Issue 

A  major  problem  of  implementing  CASE  in 
many  situations  is  that  of  cost.  The  total  CASE 
implementation  cost  for  a  technical  staff  of  200 
has  been  estimated  to  be  $6.5  million  over  a  5- 
year  period.  Companies  must  demonstrate,  or 
have  a  high  level  of  confidence,  that  this 


•  Real-time  Testmg 

•  Interface  to  Test  Equipment 

•  Automated  Testmg 

•  Configuration  Management 

•  Transparent 

•  Process  Status  Monitoring 

•  Information 

•  Automated  Documentation 

•  Tied  to  the  Software 

•  On  line  easy  access 

•  Access  to  mformation 
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magnitude  of  investment  will  pay  off.  This  is 
probably  one  reason  for  many  “pilot”  projects 
using  CASE.  Documented  results  so  far  show  no 
productivity  gains  for  six  months  to  a  year  after 
the  tools  are  introduced.  Instead,  losses  have 
been  cited  during  the  learning  period.  Many 
software  development  groups  do  not  practice 
software  engineering  methods,  which  are 
themselves  a  rather  new  discipline;  and  transition 
to  these  methods  is  not  immediate.  By  train" 
and  tradition,  software  creation  has  been  an 
individual  endeavor.  Team-programming  is 
typically  not  learned  until  progi^mers  leave 
school  and  enter  large  corporations  where  the 
corporate  culture  dictates  it. 

Usual  cost  categories  to  implement  CASE  foi 
the  first  time  are:  (1)  workstations  ($10K  to 
$20K  per  person);  (2)  the  CASE  tools  themselves 
($5K  to  $50K);  (3)  customization  to  integrate  with 
the  current  software  engineering  environment 
(estimated  to  be  at  least  20%  of  total  cost);  and  (4) 
training  costs  (this  should  include  “lost 
productivity”  costs  while  learning). 

An  Ideal  Avionics  Development  Tool  Set 

An  ideal  CASE  toolset  environment  for 
avionics  systems  development  would  have  most, 
if  not  all,  of  the  following  attributes: 

1.  A  single  user-interface  for  all  of  the 
individual  tools  of  the  set.  This  would  provide  all 
users  a  “window”  into  their  world  that  satisfies 
their  needs  and  minimizes  training  for  the 
organization. 

2.  A  common  data  base  that  provides  universal 
integrated  knowledge  to  all  users. 

3.  A  “windowing”  scheme  that  allows  each 
different  type  of  user  (planner,  analyst,  designer, 
engineer,  programmer,  tester,  manager)  to  use  the 
tool  set  from  different  point  of  view. 

4.  The  capability  to  implement  “real-time” 
documentation. 

5.  The  capability  to  maintain  traceability 
among  elements  of  requirements,  design,  coding, 
integration  of  software  and  hardware,  system 
testing,  validation  and  verification. 


6.  Provision  for  all  levels  of  avionics  system 
development:  unit  testing,  dynamic  testing,  and 
system-integration  testing. 

7.  Local  area  network  and  workstation 
implementation  for  expansion  or  tailoring  to  given 
needs.  ■ 

The  ideal  avionics  CASE  system  should 
provide  functional  support  for  a  life  cycle 
software  process  including  these  nine  functions: 
(1)  the  ability  to  create  graphical  system 
requirements  and  design  specifications;  (2)  the 
ability  to  check,  analyze,  and  cross  reference 
system  information;  (3)  management  of  an 
integrated  data  base/repository  for  software  reu.se 
and  for  storing,  managing,  and  reporting  project 
management  information;  (4)  the  ability  to  build 
software  prototypes  and  simulate  system 
performance;  (5)  capability  to  generate  code  and 
accompanying  documentation;  (6)  the  enforcement 
of  standards  and  procedures;  (7)  testing, 
validation,  and  verification  of  software;  (8) 
interfaces  to  outside  data  dictionaries  and  data 
bases;  and  (9)  a  capability  to  re-engineer  existing 
sofnvare.  The  Avionics  Directorate  of  Wright 
Laboratoty  is  supporting  efforts  that  are 
contributing  to  achieving  these  ends. 

4.  EimiREAVIONIC  SYSTEM  DESIGN 

ENVIRONMENT 

Avionic  system  design  is  becoming  more  and 
more  complex.  Avionics  systems  have  become 
more  than  several  people  can  cope  with.  A  lesson 
learned  from  many  previous  systems  is  that  the 
more  that  can  be  dealt  with  in  the  early  part  of 
design,  the  least  costly  changes  aic  in  the  later 
stages  of  the  life  cycle.  Therefore,  it  is  necessary 
to  recognize  problems  associated  with  reliability, 
maintainability,  manufacturability,  and  security, 
along  with  normal  hardware  and  software  issues 
as  early  as  possible  in  the  system  life  cycle.  The 
system  life  cycle  also  needs  to  be  traceable  from 
the  system  requirements  all  the  way  through  to 
implementation.  This  is  necessary  so  that 
intelligent  tradeoffs  can  be  made  when  system 
requirements  change.  The  size  and  complexity  of 
the  system  design  problem,  therefore,  seems  to 
point  to  a  concurrent,  automated  design 
environment  where  many  factors  can  be  traded  by 
various  people  and  maintained  throughout  the 
system  life  cycle. 


13-14 


This  problem  is  very  similar  to  the  software 
development  process.  The  problem  can  only  be 
understood  as  you  approach  the  solution  and  the 
solution  can  only  be  attained  when  you 
understand  the  problem.  Therefore,  this  process 
requires  the  ability  to  rapidly  prototype  the 
avionics  system  and  simulate  alternatives.  A  set 
of  tools  and  models  are  needed  to  represent  the 
system  and  test  out  alternatives  early  in  the  design 
process.  These  tools  would  encompass 
requirements  capture  tools,  requirements  analysis 
tools,  design  tools,  reliability  models,  cost 
models,  and  functional  simulators.  The  data  from 
these  tools  must  be  compatible  with  each  other  as 
well  as  software  and  hardware  automated  tools 
and  methods. 

5.  CONCLUSIONS 

Military  avionics  in  the  early  21st  centuiy  must 
be  cost  contained  at  approximately  30%  of  the 
(fighter)  weapon  system  flyaway  cost.  Aside 
from  cost,  availability  will  likely  be  the  next  most 
important  characteristic  for  avionics  in  order  to 
suppon  austere  basing  and  reduction  of 
personnel.  At  the  same  time,  revolutionary 
capabiliues  in  achieving  unparalleled  performance, 
stealth,  and  automation  improvements  through 
advanced  sensor  and  AI  technologies  will  become 
a  reality  shortly  after  the  turn  of  the  centuiy.  RF 
beams  will  be  pointed  selectively  in  real  time; 
ground  targets  will  be  recognized  automatically; 
aircrews  will  be  provided  machine-generated 
expert  assistance  for  mission  planning  and  tactics; 
intra  and  interaetted  fligiits  of  aircraft  will 
automatically  receive  and  transmit  battle 
management  information. 

Tl.e  issue  during  the  1990s  is  to  determine 
whether  low  cost  and  availability  is  necessarily 
contradictory  to  achieving  need^  performance.  If 
this  seeming  paradox  is  not  resolved,  less  capable 
weapon  systems  or  a  few,  highly  capable  aircraft 
will  result. 

The  technology  infrastructure  for  a  powerful 
new  avionic  system  is  being  developed  and 
should  be  mature  for  transition  before  the  year 
2000  (e.g.,  MMIC-based  RF  circuits,  multi-chip 
packaging,  flow  through  cooling,  parallel 
processing,  switched  photonic  networks, 
multifunction  RF  transmitters,  automatic  target 
recognition  algorithms,  high  resolution  EO 
sensors,  etc.). 


It  appears  that  reduced  hardware  cost, 
increased  performance,  and  improved  availabiUty 
can  be  simultaneously  achieved  through  the  use  of 
sensor  integration  and  “supercomputer” 
exploitation,  with  advanc^  packaging  and 
cooling  technologies  playing  an  important  role. 
The  use  of  a  small  family  of  both  ^  and  digital 
line-replaceable  modules  will  be  mandatory  for 
cost  containment,  along  with  the  use  of 
multifunction  apertures.  In  general,  most  of  the 
resources  across  the  sensor  systems  will  need  to 
be  shared  to  achieve  weight,  volume,  and  cost 
constraints,  as  well  as  fault  tolerance. 

The  use  of  integrated  sensor  systems  in  the  era 
beyond  2000  is  viewed  as  the  most  significant 
change  that  will  occur  because  of  significant  cost, 
weight,  and  volume  savings.  In  addition,  such  a 
system  enables  more  efficient  emission  control  for 
stealthy  operation  and  allows  the  sensor  system 
designer  to  more  easily  fuse  sensor  data. 

However,  a  significant  cultural  change  will  need 
to  be  affected  to  accept  and  adapt  to  this  concept. 
Sensor  engineers  will  need  to  be  retrained  to 
broaden  their  knowledge  base,  and  avionics 
organizations  will  need  to  be  dramatically  altered. 

System  and  software  engineers  will  be  forced 
to  undergo  similar  changes  as  the  result  of  sensor 
integration  and  the  fighter  coupling  of  mission, 
sensor,  flight,  propulsion,  and  weapon  stores 
processing. 

The  widespread  use  of  modular  avionics  and 
the  concept  of  a  flexible,  open  architecture  will 
promote  multinational,  participatory  development 
of  future  avionics. 

A  significant,  but  not  unsurmountable  difficulty 
to  be  overcome  is  software  cost.  Integration  and 
performance  both  imply  complex  software  and 
large  amounts  of  it.  It  is  conceivable  that  a  high 
performance  early  21st  century  fighter  might  need 
20-30  million  lines  of  code  for  its  operational 
flight  program,  support  software,  and  mission 
planning  software.  If  the  current  productivity  of 
approximately  10  verified  and  validated  lines  of 
code  per  day  is  not  improved,  thousands  of 
qualified  programmers  would  be  required,  making 
the  entire  venture  unweildy  and  prohibitive  in 
cost. 

Hence,  much  of  the  future  progress  to  be  made 
in  avionics  lies  with  the  progress  made  in 
improving  software  productivity  and  the  use  of 


highly  integrated  sensor  and  system  concepts. 
There  is  room  for  cautious  optimism  because  of 
the  significant  effort  being  made  in  integrated  tool 
development  and  the  focus  towards  software 
reuse,  and  the  stndes  in  RF  and  photonic 
circuitry. 
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TOTAL  SYSTEM  EFFECTIVENESS 
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COMPARISON  OF  AVIONIC  PARAMETERS 


20M 

15M 

10M 

5M. 


$15.4M 
12.7M 


COST  (FY  90$) 


$7.2M 


2878 


51 .6K 


Figure  21 


□  1990  Technology 
[S  1998  Technology  •  Federated 
H  1 998  Technology  ■  Integrated 


Efive  Pece  Software  Architecture 


Figure  22 


VERY  HIGH  SPEED  OPTICAL  NETWORKS  (VHSON) 


80FTWAME 

nCOUMKMeWTS 


p«i£UMMAinr 

KSK2N 


SOFTWARE  DEVELOPMENT  WATERFALL 

luecyci.e  model 


OCTALED 

DCStGM 


000040 


Figure  24 


■rtrnHG 


MTEQRATION 


SOFTWARE  DEVEI.OPMfNT  SPIRAL  LIFECYCLE 
MODEL 


SELECTIVE  BIBLIOGRAPHY 


This  bibliography  with  abstracts  was  prepared  to  support 
AGARD  Lecture  Series  No.  176  by  the  Scientific  ai.d  Technical 
Information  Program  of  the  U.S.  National  Aeronautics  and  Space 
Administration,  Washington,  D.C.,  in  consultation  with  the 
Lecture  Series  Director,  Dr.  Gary  L.  Ludwig,  Wright  Pa'terson 
Air  Force  Base,  Ohio. 


B-2 


AUTH 


HS 


AUTH 


ABS 


auTm 


ABS 


AUTH 


ABS 


AUTH 


ABS 


PPT# 


UTTL  Impact  of  fau)  f  tol  erant  avloo»cs  on  Mfe-cycU 
costs 

A/SCHOR  ANOREI  L  B/LEONG.  FRANK  J  ,  C/BABCOCK.  PHILIP 
S  .  IV  PAA  C/<Char1es  ^’ark  Orapar  LaPorator,  Inc 
Camo^<aO«.  MA)  in  NAECON  89,  Proceedirps  of  »ne  IEEE 
National  Aerospaca  ano  £i«ctronics  Conference  Dayton  OH 
May  22-26.  1989  Volume  A  (A90-30C76  12-01)  New  York 
Institute  of  Electrical  ana  Electronics  Enoine*>rs  Inc 
1989.  p  1893-1899 

Tr©  authors  examine  the  effects  of  a  faul t -tolerant 
implementation  of  a  miss ion-cr i t ical  avionics  function  on 
aircraft  Itfe-cyde  costs  A  triplex  reounoant 
architecture  is  contrasteO  with  a  simplex  mplementatior 
of  the  same  function  The  cost  analysis  useo  m  this  study 
accounts  for  the  major  contributors  to  .he  cost  of 
Ownership  It  Is  shown  that  an  increaswo  mission  readiness 
ana  a  high  function  reliability  during  the  mission  combine 
to  provide  a  much  higher  overall  mission  success  level  and 
consequently  a  significant  cost  advantage  for  the 
f aul t - tol erant  architecture  A  faul t - tolei  ant 
implementat Ion  of  an  avionics  function  can  significantly 
reduce  iife-cycle  costs  by  reducing  the  number  of 
additional  aircraft  required  to  achieve  desired  levels  of 
mission  readiness  and  success  The  nigh  fault  coverage 
inherent  in  such  an  impl ementat ion  increases  the 
probability  of  mission  success  by  reducing  tne  probability 
of  undetected  faults  prior  to  the  start  of  tne  mission  and 
mitigating  the  effects  of  faults  during  the  mission 
89/00/00  90A30805 


UTTL  Demonstration  of  Avionics  Module  Excnangeabi  I  ity,  via 
Simulation  (DAM£$)  program  overview 

A/STRAUSS.  JACK  B/PORTELLl  BILL.  C/OSETH.  TOOO  PAA 
A/(USAF,  Aeronautical  Systems  Olv  ,  wrignt-natturson  AFB 
OH)  C/<2YCA0  Corp  Mount  Olive,  NU)  IN  NAECON  89 
Proceedings  of  the  IEEE  National  Aerospace  and  Electronics 
Conference,  Oayton  OH,  May  22-26  1989  Volume  2 

(A90-30&76  12-01)  New  York.  Inatitute  of  Electrical  and 
Electronics  Engineers  Inc  1989,  p  660-667 
The  joint  Integrated  Avionics  working  Group  (JIAWG) 
organization  strategy  and  program  planning  to  achieve 
commonality  m  the  cone*. ''rent  development  of  advanced 
tactical  weapon  systems  in  each  of  the  three  services  is 
discussed  The  completeness,  adequacy,  and  technical 
issues  in  the  area  of  avionics  specifications  and  systems 
are  especially  complex  A  history  of  tne  significant  JIAWC 
events  in  addressing  these  common  concerns  that  led  to  the 
DAMES  program  is  dis-^ussod  The  contribution  of  the  OAMES 
tasks  strategy  and  gate-level  system  simulation 
methodology  contributions  to  the  efficient  design, 
manufacture  cost  reduction,  and  risk  reduction  of  the 
advanced  avionics  for  tnservice  weapons  systems  ©»© 
detailed  89/00/00  90A30726 


UTTL  A  test  ana  maintenance  architecture  c'emonstrated  on 
SEM-E  modules  for  fiber  optic  networks 

A/OENSEN,  CURTIS  A  e/CORLEY  JACK  H  PAA  B/IHarns 
Corp  .  Government  Aerospace  Systems  Ow  ,  Melbourne  fl) 

IN  AUTOTESTCON  ‘89  •  IEEE  Infernat 'Onal  Automatic  Testing 
Conference  Rni tade’phia.  PA  Sept  26-28  1969 

Conference  Record  (A90-28310  11-66)  New  voi  X  Institute 
of  Electrical  and  Electronics  Engineers  tne  .  1989  o 
25S-260 

The  authors  decertbe  a  general-purpose  test  and 
maintenance  architecture  for  electronic  subsystems  and  its 
demonstrat ion  In  sovera-  avionics  SEM-E  modules  for 
fiber-optic  networking  of  the  Advanced  ’actical  Fighter 
A-12.  and  other  modern  aircraft  The  results  of  applying 
this  test  and  maintenance  architecture  are  delineated  in 
terms  of  payoff,  penalty,  and  problems  encountered 
Industry  efforts  needed  to  ei iminate  some  of  the  problems 
encountered  are  discussed  89/00/00  90A283A2 


U^’'L  An  operational  perspective  of  potential  benefits  of 
microwave  landing  systems 

A/8ARRER.  JOHN  N  .  B/SINHA  AGAM  N  PAA  8/<Mnre 
Corp  McLean,  VA)  (National  Convention  of  Aerospace 
Engineers.  3rd.  New  Delhi ,  India,  F«d  26  37  1968) 

Institution  of  Engineers  (India)  Journal.  Aerospace 
Engineering  Division  (ISSN  0267-3423)  vol  69.  Sept 
1988-Mar  1969.  p  16-21 

The  rperational  requirements  of  the  ground  systems 
avionics  and  air  traffic  control  procedures  that  are 
needed  to  derive  the  maximum  operational  benefits  fro*  .m 
MLS  are  summarized  MLS  applications  are  described 
Including  reductions  In  route  length,  arrival  and 
departure  noise  exposure,  airspace  conflicts  Also 
cons iderat ion  is  given  to  improving  airport  capacity, 
operational  restrictions  due  to  US  s i t ing  problems,  and 
rotorernft  applications  69/03/00  90A23242 


UTTL  RISC  lifting  off  In  avionics 

A/WONG.  JAMES  M.  H  PAA  A/(Sanders  Associates  Inc 
Nashua.  NH)  IN  AIAA  Cdm(.uters  in  Aerospace  Conference. 
7th,  Monterey.  CA,  Oct  J-5,  1989.  Technical  Papers  Part 
1  (A90-10476  01-59)  Washington,  OC.  American  Institute  of 
Aeronautics  and  Astronautics,  1989,  p  45*51 
The  philosophy  behind  the  use  of  the  reduced  instruction 
set  computer  (RISC)  m  avionics  is  addressed,  and  the 
merits  of  RISC  versus  the  compi ©v, instruct  ion  set  computer 
(CISC)  are  examined  The  different  RISC  architectures  are 
examined  using  as  i 1 lustrat ions  the  designs  taken  from 
various  vendors  Cost  aspects  and  technology  trends  are 
briefly  considered 

AIAA  PAPER  89-2967  89/00/00  90A 10483 


UTTL  Radio  Technical  Commission  fo-  Aerenautres  Annual 
Assembly  Mretmg  and  Technical  Symposium.  Washington,  OC, 
Nov  26-30,  1988  Proceedings 

AUTM  A/JAGO  JOANN  C  PAA  A/lHad'o  Technical  Commission  for 
Aeronautics  Washington  DC)  Meeting  and  Symposium 
sponsored  by  the  Radio  Technical  Commission  for 
Aeronautics  Washington,  oc  Radio  Technical  Commission 
for  Aeronautics,  '988.  20S  p  No  individual  items  are 
abstracted  in  this  volume 

ABS  Technological  and  stanoa- J ' zat icn  problems  in  the 

development  o»  communication  avion'cs  are  examined  in 
reviews  arws  reports  Particu'.xr  attention  is  given  to  ICAO 
planning  for  future  aeronautical  commun ica t ion  standards 
digital  voice  convnunicat ion  techniques,  commun ica t ion 
systems  for  next  generation  commercial  aircraft  extending 
data  commun I  cat  ion  to  oceanic  routes.  RTCA  modp-S 
data- 1  ink  standardi za t ion  a£EC  sateiiite-systews 
standardizat ion  air  communication  using  Inmarsat  and  TAA 
support  for  future  air-ground  O’g’tal  communication  Also 
included  is  a  panel  discussion  presenting  user 
perspectives  on  aeronautical  teiecommunicat ion  Diagrams 
drawings,  and  tables  of  numerical  data  are  provided 
86/00/00  89A45875 


UTTL  The  equipment  scene 

AUTH  A/WESTON,  J  L  PAA  A/(Smiths  Industries  Aerospace  and 
Defence  Systems  Co  Londor.,  England)  IN  Civil  avionics 
-  The  future  internal lona I  scene  Proceedings  of  the 
Symposium  London  England  Mar  17  1988  IA89-24851 

06-06)  London  Royal  Aeronautical  Society  1988  p 
65-80 

A&S  A  comprehens 1 ve  evaluation  is  made  of  design  imperatives 
in  state-of - the-art  flight  control  pquipment.  which 
increasingly  exploits  digi ta 1 / i ntel l igent  and  fly-by  wire 
technologies  The  goals  of  these  development  efforts 
encompass  in  addition  to  superior  accuracy  and 
response  time  performance  greater  system  integration 
higher  reliability.  lowe>  weight,  diminished  power 
requirements .  and  lower  costs  Attention  is  given  to 
development  and  economic  trends  in  computer  RAMs  gate 
arrays,  and  memory  densities  as  well  as  to  the  design  of 
active-matrix  1 iquid-cnysta!  displays  and  their  matrix 
pixel  conf iguration  Features  of  the  software  development 
Cycle  for  flight  control  systems  are  also  noted 
88/00/00  89A24855 


UTTL  Setting  tn©  scene  -  Tre  operator's  viewpoint 
AUTH  A/FEATHCRSTONE .  0  H  PAA  A/ ( Aeronaut  I CA I  Radio  Inc 
Annapolis,  MO)  IN  Civil  avionics  -  The  future 
internat lona 1  seen©  Proceedings  of  the  Symposium  London 
England  Mar  l7  1988  (409-24851  08  06)  London  Royal 
Aeronaut  ica)  Society  1988  P  i-io 
ABS  After  an  evaluation  of  the  ways  ir  -mch  technological 

advancements  'n  electronics  can  be  exploited  for  economic 
gain  in  tne  airline  industry  attention  is  given  to  such 
©merging  technologies  as  the  Microwave  Landing  System,  the 
Mode  $  upgrade  of  the  Secondary  Surveillance  Radar  S  stem, 
and  the  Airborne  Collision  Avoidance  System  The  Airlines 
Electronic  Engineering  Committee  anticipates  that  these 
systems  will  operate  in  parallel  with  existing  ones  for 
some  time,  allowing  airlines  to  tram  with,  and  then 
transition  to.  tne  new  systems  as  economics  permit 
?8/00'00  89A24852 


UTTl  Com»arison  of  FAA  DO- 178A  and  OOD-STO-2 167A 
approach'X’i  to  software  certification 

AUTH  A/OEWALT  MICHAEL  P  PAA  A/(FAA  Seattle  WA )  AlAA 

Digital  Systems  Conference.  8th.  San  jose  CA  oct  i/-20, 
1988  8  p 

ABS  There  ar©  two  popular  standards  for  developing  avionics 
software  The  standard  used  for  commercial  aircraft  is 
RTCA/00- i78A .  Software  Cons  Iderat Ions  in  Airborne  Systems 
and  Equipment  Cer t 1 f icat ion  whereas  military  environment 
uses  000-ST0‘2i67A  Military  Standard  Defense  System 
Software  Development  This  paper  compares  these  two 
standards  and  demonstrates  that  with  some  minor 
additional  documentation  changes  software  developed  under 
the  military  standard  D0D-STD-2167A  could  be  compatible 
with  curt  I f Icat ion  requirements  imposed  by  the  Federal 
Aviation  Adiiilnistrot  ion  through  RTCA/00-178A  for 
comiierc  >  b1  aircraf  t 

RPT*  AIAA  PAPlR  88-'1044  88/10/00  89AI9864 


UTTl  Standardization  implications  -  An  air  logistics 
command  perspective 

AuTH  A/ILIFF  RICHARD  J  »4\  A/(USAF,  Wri ght -Pa t ter son  AF8, 
OH)  AIAA.  Digital  SyS‘  'ms  Conference  8th,  San  Jose  CA 
Oct  17-20  1988  5  p 

ABS  The  effect  of  various  hardware  and  software 

standardization  initiatives  on  the  logistics  command  is 
examined  In  particular  attention  is  given  to  tho  Mcdu’ar 
Avionics  System  Architecture  program,  the  concept  of  line 
replaceable  Modules  and  problems  associated  with  the 
implementation  of  this  concept,  standardization  in 
satellites  and  software  standards  It  is  noted  that  the 
end  results  of  moving  tr  standards  is  sometimes  a  higher 

front  onn  *5  'Sj'St'CC  ’ t .  mC  ts..  * 

devei(^ent  because  of  the  need  to  support  new 
technologies  which  make  the  standard  possible  in  tn©  long 
run  however,  the  life  cycle  cost  will  be  improved 

RPT«  AIAA  paper  88-3867  88/10/00  89AI9859 


UTTL  Reliability  and  waintainabi M  ty  In  modern  avionics 
eqiiipment  -  A  user's  pomt  of  view 
AUTH  A/KCNNIS,  FRANS  J  IN  ICAS  Congress.  l6th  Jerusalem 
Israel.  Aug  28-Sept  3.  <986.  Proceedings  Volume  2 
<489-13501  03-05)  Washington  OC .  American  Institute  o* 
Aeronautics  and  Astronaut ICS .  Inc  .  1938  p  1677*1682 
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ABS  The  point  of  vi«'w  of  the  user  (i  e  Qeloian  Air  Force) 

concerning  the  reliePiMty  and  maintainability  of  modern 
avionics  equipment  in  tactical  fighter  aircrafts  is 
prosontect  Past  eoperiences  by  the  Belgian  Air  Force  on 
aircrafts  such  as  the  F'64F,  f - 104G  and  Mirage  III  are 
highlighted  Maintainability  problems  related  to  the  F-16 
are  analyzed,  causes  of  lack  of  ma intatnabt I i tv  are 
indicated  and  recommendations  are  made  for  improving 
maintainability  A  special  analysis  addresses  the  F-i6 
reliability  improvement  warranty  IRIW)  A  new  approach  is 
presented  for  a  RIW  contract  which  more  evenly  distributes 
the  burdens  and  risks  between  the  contractor  and  the 
government  08/00/00  89AI3671 


UtTL  economical  technology  application  in  commercial 
transport  design 

AUTH  A/DRAKE.  MICHAEl.  L  PAA  A/(Boe<ng  Commercial  Airplane 
Co  .  Seattle  WA )  SAWE  Annual  Conference  4Cth, 

Seattle  WA  May  r6-20  1907  16  p 

AQS  An  evaluatioii  ■$  maae  of  the  development  status  and 

applicability  to  state-of-the-art  neOium-range  transport 
aircraft  of  technologies  that  may  improve  airline 
operating  cost  The  aircraft  m  question  are  of  8757 
class  Attention  is  given  to  factors  figuring  m  d-rect 
operating  costs  the  cost  effects  of  A)-Li  alloy  and 
advanced  composite  structures'  introduction,  the 
operational  advantages  of  such  systems  as  electronic 
engine  contiols  and  fly-by-wtre  ..ontrol  for  relaned  static 
stability  flight  characteristics,  and  the  effect  on 
operating  economics  of  airport  delays  that  may  be 
precluded  through  improved  .ecnnotogios '  application 

RPT*  SAWE  PAPER  1798  87/Ob/OO  88A53796 


UTTL  Rei  1  ab  I  1 1 1>;  and  life  cycle  cost  of  mi  1 1  tary,  an  craf  t 
-  The  vital  link  I  -  The  content 
AuTH  A/OANlEu  0  w  PAA  A/(Ministry  of  Defence  Procurement 
Executive  London.  England)  IN  Reliability  '87 
Proceedings  of  the  Sixth  Conference  Birmingham.  England 
Apr  14-1€,  1987  Volume  1  (A88-428L1  17-38)  London. 
Institute  of  Duality  Assurance  1907  p  38/3/1  to  36/3/4 
ABS  The  initiatives  of  the  Ministry  of  Defence  <M00)  and 

industry's  response  to  the  provision  of  models  and  methods 
for  the  evaluation  of  system  cost-effectiveness  from  the 
earliest  stages  of  development  are  examined  Particular 
attention  is  given  to  tne  relationship  between  improved 
reliability  on  the  one  hand  and  lower  costs  and  improved 
operat'onal  performance  on  tne  other  It  is  shown  why 
evaluation  tools  are  urgently  required,  and  a  strategic 
framework  for  their  development  is  provided  87/00/00 
68A42S64 


UTTL  VHStc  interoper^ioi  I  uy  standards  and  design  for  test 
fules  Tnei'  impact  on  weapon  system  support  concepts 

AUIM  A/MC0£fiM0TT,  oON  T  PAA  4/(HoneyweH.  Inc 

Minneapolis,  MN>  IN  AtlTOTESTCON  '87  Proceedings  of  the 
Interrat lonai  Automatic  Testing  Conference  San  Francisco. 
CA.  Nov  3-8  1987  <488-36528  14-59)  New  fork.  Institute 

of  Electrical  and  Electronics  Engineers  Inc  *987  p 
245-249 

ASS  7wo  recent  developments  to  microelectronics  have  the 

potential  to  s ign 1 f leant  I y  Change  tne  way  weapon  systems 
are  Supported  They  are  the  development  of  buses  to  be 
used  for  control  and  data  information  flow  between 
subsystem  maintenance  controllers,  module  maintenance 
controllers,  and  individual  elements  (chips)  of  a  module, 
and  the  inclusion  of  testable  building  blocks  m  CAO 
databases  along  with  rules  that  govern  their  use  When 
applied  to  weapon-systems  design  triese  two  concepts  can 
be  combined  to  give  an  onboard  r>ierarch*cal  maintenance 
and  diagnostic  capability  that  could  $<gn> f icant I >  change 
weapon-system  suppo-t  concepts  The  author  discusses  these 
concepts  and  their  relation  to  weapon-system  supv>ort  and 
future  automatic  test  systems  87/r»0/00  88436560 


UTTL  Application  of  an  integrated  interconnect  ion  svstem 
in  hel  , copter  wiring 

AUTH  A/GOHMAN  RICHARD  W  PAA  A/(McOonnell  Douglas 

Helicopter  Co  Mesa.  AZ)  ahS  Annual  Forum.  43rd.  Saint 

Louis  MO  May  18-20  1907  Paper  11  p 

ABS  A  rwpresenta 1 1 ve  integrated  interconnect  ion  system  (12S) 
wiring  design  was  prepared  for  the  AH-64A  helicopter  and 
compared  to  the  existing  wiring  design  to  quantify  the 
production  cost  savings  and  the  lorhnical  risks  involved 
in  the  design  concept  Expertnerts  m  FMl/CMC  performance 
and  facncaiiOn  of  a  test  harness  were  combined  with  th© 
analytical  evaluation  effort  The  conclusions  drown  from 
this  study  indicated  that  the  I2S  is  not  effective  as  a 
concept  to  design  replacements  for  existing  harness 
assemblies,  but  it  does  present  sufficient  production  cost 
saving  in  a  new  w-ring  design  effort  to  be  seriously 
considered  in  the  design  trade  evaluation  87/05/00 
88A22800 


UTTl  Ir-proving  avionrcs  acquisition  and  support  from 
conceptual izat ion  through  operations 

AUTH  A/GEBMAN  OEAN  8/SHULMAN  Mf  PAA  ft/fO»rtd  r-.-p  Si 
Muiiica  uA;  IN  Avionics  in  conceptual  system  planning 
Proceedings  of  the  Eighth  Annual  IEEE  Symposium  Dayton 
(iH  Dec  3  1986  <A88-169t3  05-66)  New  ro-k ,  Institute  of 

Electrical  and  Electronics  Engineers.  Inc  .  1986.  p 
69-76 

A8S  Th©  prooion  of  the  suppor tab  1 1 ♦ t /  Of  avionics  equioment  is 
examined  with  emphasis  on  sn  approach  to  acquistt'on  and 
soppo.  t  that  begins  with  the  conceP*  formulation  stage  and 
follows  fhrough  the  equipment's  full  life  of  service  Th© 
hasis  fo**  such  an  approach  is  summarised,  and  a  broad 
strategy  for  enhancing  a/ionics  supportaPI  I  U/,  is 


formulated  Sorse  tradeoffs  are  proposed  whicn  should  be 
made  at  the  concept  formulation  stage  to  further  enhance 
the  benefits  of  the  strategy  for  i.-iproving  avionics 
suppor tab  1 1 1 ty  86/00/00  08A16919 


UTTL  Th©  design  agent  process  at  a  strategy  for  future 
avionics  competition  enhancement  and  quality  assurance 
tllTH  A/OELANEY  WILLIAM  U  PAA  A/(Charles  Stark  Draper 
Laboratory  Inc  ,  Cambridge  MA)  IN  Avionics  m 
conceptual  System  planning.  Proceedings  of  the  Eighth 
Annual  IEEE  Symposium.  Dayton,  OH,  Dec  3.  1986  (488-16912 
05-66)  New  fork  Institjte  of  Electrical  and  Electronics 
Engineers  Inc  1986,  p  53-58 
ABS  The  design  agent  concept  of  acquisition  management  is 
examined  with  particular  reference  to  future  avionics 
acquisition  requirements  Th©  activities, 
responsibilities,  and  competition  enhanc  ng  benefits  of 
the  design  agent  approach  to  acquisition  management  are 
discussed  and  illustrated  bv  several  different  appi icat  on 
examples  It  is  claimed  that  the  design  agent's  ability  to 
uniquely  establish  and  control  multiple  contractors  for 
competition  enhancement  purpose*  has  direct  relevance  to 
the  need  for  improved  ocquisiilon  strategies  on  select  6  3 
programs  86/00/00  88A16918 


UTTL  The  avionics  acquisition  process  beyond  the  year 
2000 

AUTm  A/LAVOIE,  R  P  B/CULP  am  in  Avionics  m 

conceptual  system  planning,  Proceedings  of  the  Eighth 
Annual  IEEE  Symposiuh  Dayton  OH  Dec  3  1986  <488-16912 

05-66)  New  vork.  Institute  of  Electrical  and  E ’ ectf on ics 
Engi  leers  Inc  .  1986,  p  45-49 

ABS  The  current  weapon  system  acquisition  and  support  process 
IS  examined  with  emphasis  on  problems  related  to  the 
useful  Mf©  Of  microelectronic  component  technoiogv 
requirements  changes  and  technology  obsolescence  The 
need  for  changes  in  the  present  acquisition  process  is 
emphasized  and  it  is  shown  that  a  good  solution  should 
accept  the  reality  of  long  development  programs  and  adjust 
the  process  t'  jeal  with  rapidly  developing  technology 
requirements  changes,  and  obsolescence  The  critical 
elements  of  the  solution  are  long-term  planni-ig,  sustained 
investment  for  impro»ing  systems,  managed  change  and 
incremental  transfer  of  System  responsibility  66/00/00 
88416917 


UTTl  Avionics  'n  conceptual  system  planning  Proceedings 
of  the  Eighth  Annual  IEEE  Symposium  Dayton  Or,  Dec  3 
1986  Symposium  sponsored  by  IEEE  New  York  Institute  Of 
Electrical  and  Electronics  Engineers.  Inc  1986  92  p 

For  individual  items  see  A0e-I6913  to  Ae8'l6920 
ASS  The  papers  presented  m  this  volume  deal  with  various 

aspects  of  the  problem  of  integrating  avionics  into  tota' 
System  design  during  the  concept  formulation  stage  with 
particular  attention  given  to  impacts  pun  definition  of 
requirements  future  avionics  concepts,  tradeoffs  between 
th©  veniclo  propulsion  and  avionics  integration  of 
suppor tab> 1 1 ty  into  the  design  and  acquisition 
strategies  Papers  are  included  on  system  architecture 
design  and  tools  fo-  a  distributed  avionics  system  the 
design  agent  process  as  a  strategy  for  future  av.onics 
corpetition  enhancement  and  quality  assurance  the 
avionics  acquisition  process  beyond  the  year  2000,  ard 
electromagnet  ic  compa t ib 1 1 1 1 y  modeling  for  future  avionics 
systems  86/00/00  83A16912 


uITL  Reliability  ma i n ta inabi 1 i ty  and  testability  of  RAF 
equipment 

AUTM  A/IZZARO  U  .  B/MRLOT  P  0  G  PAA  B/(RAF  Lcndon. 
England)  IN  Cost-effective  avionic  and  weapon  systems 
Proceedings  of  th©  Spring  Convention  London,  England  May 
Id  15.  1986  (A87  48051  21-83)  i.OhdOn.  Royal  Aeronautical 
Society.  1987  p  9  1-9  10 

ABS  The  RAF's  institutional  'tew  of  cost-effectiveness  ’n 

avionics  and  weapons  systems  emphasizes  life  cycle  costs 
(lCCs)  rather  than  acquisition  costs  Re’iabiiity 
maintainability  and  testability  are  hold  to  be  critical  to 
th©  achievement  of  cost  ©f feet  iveness,  and  ere  invested  in 
to  the  requisite  degree  before  a  piece  of  equipment  is 
allowed  to  enter  service  Attention  is  presently  given  *o 
ICC  costing  practices  the  operational  costs  of  equipment 
unret laoi I  I ty  uSAF  experience  w.th  reliability  and 
raamta  inabi  1  I  ty .  testability  design  provisions  and 
built-in  test  technx>logy  capability,  projections 
e7/<X>/0C  87A48060 


UTTL  Modular  ICNIA  packaging  technology 

AUTm  A/PORAOI^M,  FRANK  PAA  A/( Texas  Instruments  Inc 

Avionics  Systems  Dw  McKinney)  IN  Digital  Avionics 
Systems  Conference,  7th.  Fort  worth  TX.  OCt  13-16  1986 

Proceedings  (a37-3145i  13-01)  New  York  Institute  of 
Electrical  and  Electronics  Engineers  Inc  ’986  p 
753-756 

•&>  significant  size  weight  power  and  roiiab'lity 

I  iproverients  can  be  acnioveo  in  next  generation  aviomcs 
by  the  modular  Integration  of  similar  functions  into  a 
fault  tolerant  reconf igurabl o  architecture  Th©  Integrated 
Communication  Navigation  Identification  Avionics  program 
(ICNIA)  is  accomplishing  this  task  with  a  combination  of 
modular  Circuit  designs  using  VHSIC  technology  irprovod 
packagir.g  designs  incorpora  1 1 -g  surface  mount  component 
technology,  and  a  modular  ‘wr- level  maintenarvce  support 
concept  for  reduced  life  cyci©  cost  This  article 
concentrates  or.  the  modular  packaging  technology  o*  tfva 
digital  processor  subsystem  06/00/00  87A31546 
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UTTL  F/A-16  Hornet  Rellabtlity  development  testing  •  An 
update 

AUTM  A/ROSCER  W  R  PAA  A/(McOonnel1  Aircraft  Co  .  Saint 
Louis  MO)  IN  Institute  of  Environmentel  Sciences 
Annual  Technical  Meeting  32no  Dallas  and  Fort  Worth  Ta. 
May  C-8  1986  Proceedings  U87-26026  10-38)  Mount 

Prospect,  IL,  Institute  of  Environnenta)  Sciences  >986. 
p  86-92 

IBS  The  characterlst Ics  Of  the  Operational  Mission 

Environments  (OMEs)  used  to  accelerate  the  Identification 
of  failure  modes  and  provide  corrective  action  early  in 
the  Reliability  Development  Test  (ROT)  program  of  the 
F/A-18  Hornet  are  discussed  Different  OMEs  are  needed  tor 
the  develomvnt  test,  burn-in,  and  AH  Equipment  test 
because  of  the  different  results  expected  The 
operationally  realistic  environments  and  test  acceleration 
generjted  more  failures  than  traditional  reliability 
testing,  and  half-life  vibration.  750  hours  vibration 
Simulation,  and  high  thermal  rate  cycling  were  all 
up-f-ont  tests  ae/CO/OO  87A26035 


UTTL  An  expert  system  for  the  configuration  of  aircraft 
modular  VSCF  generator  systems 
AU’H  A/HO  T  -L  e/BAVLES,  R  A  ,  C/SIECER  £  R  PAA 
C/ ( West inghouse  Electric  Corp  ,  Baltimore,  MO)  IN 
NAECON  *986,  Froceedings  of  tne  National  Aerospace  and 
Electronics  Conference  Dayton  OH  May  19‘23  1986 

volume  1  (A87-16726  05-01)  New  fork.  Institute  of 
Electrical  and  Electronics  Engineers.  1986,  p  304-311 
ABS  The  modular  VSCF  (Variable  Speed  Constant  Frequency) 
electrical  systems  are  designed  using  the  latest 
technology  and  modular  deiign  techniques  The  system  is 
separated  into  standard  nodules  to  redu.e  the 
manufacturing  cost  and  Improve  tne  product  quality  ana 
services  This  tool  is  an  expert  system  which 
automatically  configures  the  mooules  required  for  a 
particular  application  The  automatic  conf igurat ion  expert 
System  is  a  rule-based  synthesis  system  whose  domain 
encompasses  the  matrix  ot  standard  modules  The 
configuration  system  is  built  by  using  a  ru>e*based  expert 
system  development  tool  0PS5.  in  a  VAX  11/750  computer 
It  has  the  ocmaih-snecif ic  knowledge  necessary  to 
configure  tne  generators  embedded  in  its  rule-base  and 
exhibits  expertise  to  place  the  modules  in  the  proper 
arrangement  based  on  customer  speci f icat Sons  and  dcs>qn 
criteria  86/00/00  87A16755 


UTTL  LAMPS  MK  III  •  A  'New  Look'  success  Story 

AUTH  A/GOOO  T  M  PAA  A/dBM  Corp  Federal  Systems  Olv,  . 
Owego,  Nv I  IN  1986  Annual  Reliability  and 
Maintainability  Symposium,  Las  Vegas.  NV  Uanuary  28-30. 
1986  Proceedings  (487-15401  04  38)  New  fork,  institute 
of  Electrical  and  Electronics  Engineers.  Inc  ,  1986  p 
1*11  155 

aSS  The  reliability  enhancement  elements  incorporated  into  the 
LAMPS  MK  III  development  program  are  desc  ibed  New 
elements  included  conservative  derating  criteria  to  ensure 
tret  a  20-yr  serv'ce  life  would  be  available  from  99 
percent  of  the  30  C >0  compohents  of  the  integrated  system 
Other  program  elements  are  parts  selection  and  a  test 
analyze,  and  *\x  program  A  reliability  estimate  for  the 
Sh-608  helicopter  exceeded  the  rei iab»i i t tes  of  mther 
current  systems  by  a  factor  of  2  3  86/OC/OO  07A15415 


UTTL  Air  Force  a tandardiz log  avionics 
AUTH  A/MONAHAN,  G  .  jR  PAA  A/<USAF.  Office  Of  the  Deputy 

Chief  of  Staff  for  Research.  Development  and  Acquisition. 
Washington.  OC )  Defense  Elnctromcs  ( ISSN  0278*3479) 
vol  17  Aug  1985  0  120-122.  125.  126.  128.  130 

ABS  Taking  a  muttileval  approach  towards  the  stendardizat ion 
of  avionics  -  in  comporents  circuit  boards,  black  boxes, 
hardware  and  software  -  the  USAF  is  seeking  to  reduce 
costs,  incr«sse  1 nteroperab 11 1 ty  and  make  room  for  the 
technology  of  the  future  Break throughs  in  computer  and 
electronics  technologies  have  enabled  hardware 
standardizat ion  on  the  highest  level  the  line -replaceable 
unit  standardizing  the  form  fit  and  function  (F3)  of 
such  units  promises  significant  savings  in  support  and 
odvelopment  costs  Software,  applicability  architecture 
organizational  structure  implemrntat ion,  current 
advances  and  future  directions  are  topics  covered 
85/08/00  85A44074 


UTTL  The  relationship  between  an  advanced  avionic  system 
architecture  and  the  elimination  of  the  need  for  an 
Avionics  Inter  mediate  Shop  (AIS) 

AUTH  a/aBRAHAM  S  j  PAA  A/(General  Dynamics  Corp  .  Fort 
worth,  TX)  IN  AUT0TE5TC0N  '83  Proceedings  of  the 
Conference  Fort  Worth,  TX  November  1*3.  1983  (A85-26776 
M-59)  New  vorx.  Institute  of  Electrical  and  Electronics 
Ergtnotrs,  Inc  1983,  p  206-211 
A3S  While  Avionics  Intermediate  Shops  (AISs)  havn  in  the  past 
been  required  for  military  ai-craft,  the  emerging 
VLSI/VMSIC  tochhol'Tgy  has  giver  rise  to  the  possibility  of 
novel  well  partitioned  avionics  system  architectures  that 
obviate  the  high  spare  parts  costs  that  formerly  prompted 
<><iu  ;u»)iri«u  me  existence  of  an  Ais  ruture  avionics  may 
therefore  be  adequately  and  economically  supported  by  a 
two’lcvol  maintenance  system  Algebraic  general Izat ions 
are  prevented  for  the  analysis  of  the  spares  costs 
implications  of  alternative  design  partitioning  schemes 
for  future  avionics  83/00/<X>  8SA36S04 


UTTL  Trends  in  digital  engine  control  *  Integration  of 
propulsion  control  with  flight  control  and  avionic  systems 
in  future  military  and  commercial  aircraft 
*UTH  A/«rCL£$,  E  $  PAA  A/(0owtv  &  Smith  Indu'tries 


Controls  Ltd  .  Cheltenham.  Glos  .  England)  IN  Design 
ana  advanced  concepts  of  avlonics/weapons  system 
integration;  Proceedings  o*  the  Symposium,  London. 

England  April  3  4  1984  (A85-31456  08-01)  London  Royal 

Aeronautical  Society  1984.  9  p  Research  supported  by  the 
Ministry  of  Defence  of  England 

ABS  This  paper  discusses  future  trends  in  engine  control  and 

addresses  the  integration  of  flight  control  and  propulsion 
control  both  in  commercial  and  In  future  advanced  military 
aircraft  Such  aircraft  nay  employ  sustained  supersonic 
cruise  and  maneuvarlng  flight  thrust  vectoring  and 
extensive  variable  geometry  features  The  paper  outlines 
the  factors  which  force  the  integration  of  systems  the 
benefits  hoped  for  and  the  status  of  current  work  It 
discusses  the  effects  of  integration  on  inter-system  and 
inter-orgaolzatlonal  interfaces  and  the  methods  and 
technologies  needed  to  achieve  the  ends  being  sought 
within  anticipated  timescales  84/(X>/00  85A21466 


UTTL  Man-machine  integration 

AUTH  A/ROE.  r.  PAA  A/(Brttish  Aerospace,  PLC.  Brough.  N 

Humberside.  England)  IN  Design  and  advanced  concepts  of 
avlonics/weapons  system  integration.  Proceedings  of  the 
Symposium.  LOiidon.  England,  April  3.  4  1984  (A8S-21456 

08-01)  London.  Royal  Aeronautical  Society  1984,  9  p 

ABS  Attention  is  given  to  British  studies  addressing  i  iestlons 
of  pilot  cockpit  task  optimization,  and  the  ovaraP  system 
architecture  required  to  meet  the  operational  requirements 
imposed  for  next-genarat lon  tactical  combat  aircraft  in 
the  sphere  of  communications  The  Tactical  Comba  Aircraft 
Avionics  Demonstrator  Rig  Is  devoted  to  the  in* wst igat Ion 
of  such  issues  as  total  system  integration,  interface 
standardizat ion,  effect ive  subsystem  intercommunlcat ion 
system  degradation  amel lorat ion,  and  improved  maintenance 
procedures  The  architecture  under  development  has  a 
multibus  hierarchy  and  implemehts  data  transmission 
standard  15538  for  subsystem- to-suDSystem  and  bus-to-bus 
communication  Emphasis  is  given  to  the  influence  of  pilot 
needs  on  system  design  and  implementation  84/00/00 
85A2I463 


UTTL  Integrated  communications  *  A  designers  view 
UTH  A/SRICRLEy.  W  E  PAA  A/(MarCOn1  Avionics,  ltd  . 

Airadio  Products  oiv  .  Basildon.  Essex  England)  IN 
Design  and  advanced  concepts  of  avionies/weApons  system 
ntegration  Proceedings  of  tne  Syf^poslum,  London, 

England  Apr , i  3  4  1984  (A85-41456  08*01)  London,  Royal 

Aeronautical  Society.  i984.  7  p 

ABS  An  integrated  aircraft  communications  system  should  ensure 
high  confidence  levels  for  all  phases  of  a  task  or 
mission,  allow  effective  operation  at  the  lowest  possible 
crew  workload,  and  be  cost-e*feetiva  with  respect  to 
equipment  size  weight  power  demand,  reliability  and 
maintainability  It  IS  noted  thai  while  tne  technology  for 
control  and  display  system  integration  is  available  the 
techniques  required  m  common  comnunicat ion  signal 
processing  remain  to  be  developed  Attention  is  given  to 
the  unique  integration  problems  encountered  in  tne 
man/machine  interface  of  control  and  display  systems,  the 
acquisition  and/or  transmission  of  communication 
intelligence  and  signal  processing  84/(30/00  85A21462 


UTTL  High  density  "oduiar  avionics  packaging 

AUTH  A/POR40ISM.  f  PAA  A/(Texas  Instruments  Inc  Dallas, 
TX)  IN  Digital  Avionics  Systems  Conference.  6th 
Baltimore  MD.  December  3-6.  1984.  Proceedings  (A85-17S01 
06-01)  New  York  American  Institute  of  Aeronautics  and 
Astronautics.  1984,  p  634-840 

ABS  Requirements  and  design  rqrif  igurat  Ions  for  high  density 
modular  avionics  packaging  are  examined,  with  particular 
attention  given  to  new  hardware  trends,  the  design  of 
high-density  standard  modules  (HDSM's).  and  HDSM 
requirements  The  discussion  of  the  HOSM's  covers  thermal 
management,  system  testability,  power  supply  and 
performance  specifications  The  general  design  of  an 
Integrated  hosM  demonstrat Ion  system  currently  under 
construction  IS  briefly  desc-lbed  and  some  test  data  are 
presented 

RPTW  AIAA  PAPER  84-2749  84/00/00  B5A17898 


v'TTL  A  standard  computer  bus  for  MIL -STD- 1750A  avionics 

computers 

AUTH  A/PfNN.  D  .  B/LEVV,  S  .  C/LOKfR.  E  PAA  B/{  Israel 
Aircraft  Industries.  Ltd  Tel  Aviv  Israel).  C/(E)Oit 
Computera,  Ltd  ,  Haifa.  Israel)  IN  Digital  Avionics 
Systems  Conference  6tn.  Baltimore,  PAD.  December  3-6, 

1984  Procaedlngs  {AS5-1780I  06*01)  New  Vork,  American 
Institute  of  Aeronautics  and  Astronautics.  1984.  p 
393*398 

ABS  While  MIL -STD* I750A  describes  an  instruction  set 

architecture  (ISA),  the  appi icat ton  of  this  ISA  requires 
the  usage  of  a  data  and  address  but  system  which  permits 
efficient  communication  between  the  epu,  r»e*pry.  and 
application  oriented  input/output  devices  The  data  and 
Afdress  bus  system  design  and  implementatic.s  is  influenced 
y  the  design  of  the  epu  and  main  martory  since  these  two 
devices,  in  general,  are  the  main  users  of  the  bus  syste>a 
The  Lavi  avionics  system  utilizes  a  standardized  data  and 
address  bus  system  (called  L-BUS)  for  use  in  the 
MIL-3T0- 1790A  computers  which  are  embedded  in  the  various 
components  o<*  »he  avionics  system  The  L*BUS  is  described 
and  is  proposed  as  u  potential  s*andard  bus  for 
MIL-$ro*1750A  Implementations 

RPTa  A»AA  PAPER  84*2679  84/00/00  85A17360 


UTTL  F404  new  standards  for  fighter  aircraft  engines 
AUTH  A/RICMER.  B  A  ,  B/POWEL  ^  F  .  IV  PAA  B/(Genera1 
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Electric  Co  .  Lynn,  MA)  IN  International  Council  of  the 
Aeronautical  Sciences.  Congress.  14th.  Toulouse.  France 
Septemoer  9-i4  1984.  Proceedings  Volume  i  (A64-44926 

22-01)  New  York.  American  Institute  of  Aeronautics  and 
Astronautics  1984,  p  476-482 

ABS  Design  features,  performance  capabilities  ana  applications 
of  the  F404  jet  engine  are  described  The  F404  supplies 
16-22  kib  thrust.  IS  1&9  In  long  and  35  In  in  diameter 
and  has  a  pressure  ratio  of  25  1  The  engine  inc'udes  wide 
Chord,  low  aspect  ratio  fan  blades  enhanced  aerodynamics 
and  a  high  stall  margin  Early  usage  has  revealed  an 
unrestricted  throttle  movement  throughout  the  performance 
envelope,  a  3  25  sec  interval  from  idle  to  full  power, 
high  inlet  distortion  tolerance,  reliable  air  starts  and 
dependable  afterburner  light  The  digital  controls  are 
built  into  two  ceramic  modules  which  permit  easy 
installation  of  redundancy  Testing  has  surpassed  500  hr 
In  the  F-20  and  will  be  initiated  in  the  f/A-i8  Other 
potential  applications  are  In  the  MAS39.  the  A  6  the  ACX 
demonstrator  and  the  X-29  84/00/00  84A44981 


UTTL  Digital  electronic  f1ign»  decks  -  Tne  outlook  for 
comnercal  aviation 

AUTH  A/CLAY,  C  W  PAA  A/(Boeing  Commercial  Airplane  Co 

Seattle,  WA)  (Institu<.o  of  Electrical  and  Electronics 
Engineers,  Annual  Symposium,  5th,  Dayton  OH.  Nov  30 
1983)  IEEE  Transactions  on  Aerospace  and  Electronic 
Systems  IISSN  0018-9251).  yol  ArS-20.  May  1984.  p 
221-226 

ABS  Digital  avionics  are  increasingly  able  to  reduce  overall 
commercial  airliner  costs  through  tneir  great  reliability 
and  flexibility  of  operation  Attention  is  presently  given 
to  the  development  of  modular  control  units  for 
fly-by-wire  and  power-by-wlre  directional  controls  and 
engine  throttle  controls  as  well  as  the  design  features 
of  a  network  of  multisystem  digital  data  buses  which  can 
be  developed  to  manage  the  complex  interchange  of  data 
among  Interrelated  digital  systems  throughout  an  aircraft 
64/05/00  84A36907 


UTTL  Thermal  character i st tcs  of  standardized  Air  Force 
avionic  enclosures 

VUTH  A/FPANKLIN  0  L  .  6/LEONARO.  C  F  PAA  e/(80«ing 

Aerospace  Co  .  Seattle  wA)  aIAa.  $ae.  ASME,  AlChC  and 
ASMA  Intorsociety  Confererce  on  Environmental  Systems, 
13th  San  Francisco,  CA  July  ii-tJ.  iSi3  li  p 

ABS  To  resolve  the  question  of  avionic  cnclosu'e  energy 

dissipction  limits  and  develop  thermal  design  data  on 
MIL-STD-XXX  style  enclosures,  a  senes  of  thermal 
analyses,  the  majorit.  of  which  were  performed 
steady-state  wore  carried  out  using  an  updated  version  of 
the  ENOLOS  thermal  analysis  program  Results  based  on  the 
use  of  ceramic  enp  earners  from  both  initial  eoo  updated 
analyses  and  test  results  are  presented  usir>g  cata 
collected  on  the  heat  exchanger  card,  and  clamp 
conductances,  together  wi*h  device  conductances,  plots  of 
junction  temperature  versus  power  enclosure  power 
dissipation  were  constructed  Properly  constructed  size 
2  8  MCU  standard  enclosures  may  operate  at  power  leve’s  of 
*  watt/cu  in  without  incurring  excessive  junction 
temperatures  To  achieve  the  same  power  densit  es.  size 
9-12  MCU  enclosures  w'th  side-mountod  heat  exchangers 
require  hign  conductance  ctreuM  cards  and  card  damps 

RPT*  SAE  PAPER  831103  83/07/00  84A29038 


UTTL  Avionics  stanoardizat ion  •  Oo'f  ana  dont's 
AUTH  A/RICKER,  R  K  PAA  './(USiF  Wr .gnt -Pat terson  AFB  OH) 
IN  Digital  Avionics  Systems  Conference.  5th  Seattle  WA 
October  31-NovemOer  3  1983.  Proceedings  (A84-2e70l 

11-06)  New  York  Institute  of  Electrical  and  Electronics 
Engineers,  1983.  P  23  1  1-23  1  5 
ABS  The  paper  covers  a  broad  range  of  lessons  learned  in  the 
last  decade  of  avionics  stanoardizat  ion  activities  witmn 
•he  Air  Force  It  cove» s  technical  and  nanagemrnt 
cons iderat ions  and  traces  a  number  of  projects  from 
Idealistic  goals  to  the  reality  of  implementation  The 
hardware  area  will  address  criteria  for  selection,  the 
spec* f icat ton,  finding  the  customers  balancing  market 
realism  against  the  promises  of  advocacy,  and  the 
necessity  'or  end-to-erd  planning  Specific  examples  with 
mini-case  histories  of  UH*  radios,  tacans,  InSs 
altimeters  air  data  computers.  da*a  recorders,  etc  wl>i 
be  used  to  illustrate  points  Current  interface  standards 
Such  as  MR  $TD  1553  and  i760  will  be  evamlned  relative  to 
their  evolution  and  acceptance  The  issue  of  validation 
and  contirvjed  maintenance  ano  supPO'-t  will  be  covered  Tfie 
software  standards  of  MIL  STD  1569  and  1750  will  be 
treated  'n  a  similar  manner  The  impor-tance  of  a  clear 
waiver  crocess  and  the  value  of  broad  based  u*er  groups 
will  be  highlighted  The  Question  of  what  level  of  Support 
se-vices  that  need  to  ba  provided  off  lino  to  insure 
acccptariwv  will  bo  addressed  83/00/00  84A26603 


UTTL  Fault  tolerant  flight  control  avionics  integrat.on 
using  MIL-STO- 15538 

AUTH  A/MCSHARRY  M  E  PAA  A/(Boeing  Ml  I  itary  Airplane  Co 
Seattle,  wA)  IN  Digital  Avionics  Systems  Conference. 

5th  Seattle,  WA,  October  St-November  3,  1983.  Proceedings 
(A84-267C’  11-06)  New  York  Institute  of  Electrical  and 
Electi'onics  Engineers  1983  p  11  1  1-11  1  8 

ABS  While  thh  design  of  intograteo  systems  using  distributed 
processing,  l lerarchtcal  architectures,  and  data  cases, 
provides  the  nreatwer  -.-.w  f,  c,». 

propagation  compromioes  that  tend  to  more  tightly  couple 
integrated  system  coriponents  may  be  needed  in  order  to 
satisfy  performance  reqoiremen.s  Attention  is  presently 
given  to  the  mR-STD'1SE3B  integrated  system  data  bus 
which  IS  marginally  capable  of  satisfying  the  data 


transfer  requirements  for  both  flight  control  and  mission 
avionics  and  whose  mission  avionics  functions  must  be 
Implemented  with  a  higher  level  of  redundancy  if  the 
mission  functions  affect  flight  safety  Redundancy  can  be 
attained  through  hardware  replication  as  well  as  analysis 
83/00/00  84A26744 


UTTL  The  missing  link  for  advanced  avionics  systems 
executives 

AUTH  A/LEEPER.  K  R  PAA  A/(Boe1ng  Ml  1 1 tary  Airplane  Co  . 
Advanced  Airplane  Branch,  Seattle,  WA)  IN  Digital 
Avionics  Systems  Conference,  5tn.  Seattle,  WA  October 
31-November  3.  1983,  Proceedings  (A84-26701  11-06)  New 
York  Institute  of  Electrical  and  Electronics  '’ngmeers. 
1983  p  261-266 

ABS  An  avionics  system  executive  was  developed  with  the  aid  of 
the  Digital  Avionics  Information  bystera  (DAIS)  program 
This  executive  was  coded  mostly  in  nigh-order  language 
with  hardware  interfaces  in  machine  code  However,  it  was 
found  that  the  DAIS  executive  was  more  complev  than 
necessary  for  many  applications  It  was,  therefore, 
decided  to  eliminate  asynchronous  operations  from  the 
executive  As  a  rasult  of  this  decision  the  Single 
Processor  Synchronous  Executive  (SPSE)  was  obtained 
Developments  with  respect  to  a  further  evolution  of 
standards  continued,  however,  and  revisions  appealed  which 
were  not  included  in  the  DAIS  evolution  The  present 
investigation  is  concerned  with  the  efforts  of  an  American 
aerospace  company  to  update  the  SPSE  to  HIL-$T0- 17S0A  and 
MIL-STD- 15896  It  IS  pointed  out  that  the  1750A  SPSE 
represents  the  missing  link  in  the  evolution  of  the 
avionics  executive  of  yesterday  to  the  advanced  executive 
of  tomorrow  83/00/00  84A26704 


UTTL  EME  susceptibility  testing  of  aircraft 
AUTH  A/CLARK,  0  £  .  B/HEATHER.  F  W  PAA  A/{Georgia 

Institute  of  Technology.  Atlanta  QA).  B/(U  S  Navy 
Naval  Air  Test  Center,  Patuxent  River  MD)  IN  NAECON 
1983,  Proceedings  of  the  National  Aerospace  and 
Electronics  Conference.  Dayton  OH  May  17-19.  983 

volume  1  IA84-16526  OS-OD  New  York.  Institut'  of 
Electrical  and  Flectronics  Engineers.  1983  p  lS8-i6i 
aB$  the  Navdi  Air  Test  Center.  Patuxent  Rivxr  Maryland,  has 
the  task  of  conducting  tests  and  e  'luatlons  on  naval 
aircraft  to  assure  compliance  with  EME  (el ectromagnet ic 
environment)  susceptibility  specifications  The  NATC  is 
developing  a  facility  cai’ea  the  Electromagnetic 
Environmental  Gereration  System  (EMEOS)  to  perform  me 
system-level  susceptibility  tests  This  paper  describes 
the  EMECS  facility  ana  its  support  irig  instrumentat  ion  and 
examines  the  engineering  aspects  of  upgrading  the  EMECS 
83/00/00  84A 16540 


uTTl  Role  of  standards  with  integrateo  control 
AUTH  A/CADBOlS.  R  G  PAA  A/(L<';ar  Siegler.  Inc  Astronics 

Div  Dayton  Oh)  IN  American  Control  Conference  1st 

Ar^l  ington  VA.  dune  14-16.  1982.  Proceedings  Volume  2 
(A83-37076  l7-o3)  New  ^ork .  Institute  Of  Electricel  ana 
Electronic;  Engineers.  1982,  p  588  589 

A6$  The  effect  of  standaroizetion  on  the  applicetion  of 

integrated  control  technology  to  military  aircraft  is 
discussed  in  terms  of  a  latent  conflict  between  the  cost 
benefits  of  stanoerdized  systems  end  those  attainable  by, 
implementing  new  technologies  unaccounted  for  by  the 
standards  The  signal  *  interface  standard  MIl-sTC-1553 
while  beneficial  for  connecting  avionic  systems  that  need 
to  interact.  ’S  found  to  be  potentially  inefficient  for 
self-contained  packages  (such  as  those  being  developed  for 
integrated  flight  and  propulsion  control),  and  less 
reliable  for  components  requirit>g  the  exchang*  of  very  few 
signals  Architecture  standards  referring  to  instruction 
sets  and  high-order  languages  need  to  be  applied 
pragmatically  focusing  on  form,  fit,  and  function 
computer-aid  programs  allowing  access  in  natural  English 
may  be  able  to  achieve  the  benefit  goals  of  a  standardized 
high-order  language  82/00/<X>  83A37104 


UTTL  Benefits  of  rsission  profile  testi-g 
AUTH  A/WAGNCft.  J  F  .  in  D/BURKHARD.  A  M  PAA  A/(USAF. 
Aeronautical  Systems  Div  Wr ight -Pat terson  AFB  OH), 
8/(OSAF  flight  Dynamics  Laboratory,  Wr ight -Pat terson  AFB, 
OH)  IN  Environmental  -tress  impact  and  environmental 
engineering  methods  Proceedings  of  the  Twenty-seventh 
Annual  Technical  Meeting  on  Emerging  Environmental 
Soliitlons  for  the  Eighties  Los  Angeles  CA  May  5-7 
1961  VO’um©  1  (A83-31476  13-38)  Mt  Prospect.  IL 
Institute  of  Environmental  Sciences,  1981,  p  26*31 
ABS  Tangible  and  intangible  benefits  of  combined  environment 
reliobil.ty  testing  (CERT)  are  described  in  terms  of  the 
perspectwe  of  the  acqjlsitor  lOglstician  and  user  of 
avionics  equipment  Both  cost  saving  benefits  an-i 
operational  ef foctiveness  impacts  are  discussed  When  used 
as  a  test -analyze- r lx  growth  test  program  in  the 
acquisition  process.  CERT  benefits  all  the  decision  makers 
In  the  equipment's  life  Cycle  This  beno'it  is  obtamea 
without  significant  adverse  impact  on  performance  as 
neasured  agams*  established  parformance  factors  used  by 
decision  makers  Total  acquistlon  cost  comparisons  are 
Shown  81/00/00  e3A31481 


UTTl  Jovial  language  control  procadurex  with  a  view 
toward  Ad.s 

AUTH  A/KNOOP.  P  A  .  B/EVANS.  B  R  PAA  B/(J$AF. 

Wright-Patterson  AFB.  OH)  In  NAECON  1982  Proceedings 
of  the  National  Aerospace  and  Electronics  Conference 
Dayton.  Dm  May  18-20  1982  volume  2  (A93- 11083  01  011 

New  YorK,  Institute  of  Electrical  and  Electronics 
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Eng«n**rs.  Irw  .  1982,  p  9S3-960 
ABS  t>OVIAL  Is  the  interim  stanperd  languaoe  for  Air  Force 

avionic*  enoedded  computer*  untU  Ada  becomes  available 
The  i^OVIAL  Language  Control  Facility  (LCF)  has  developed 
and  fine-tuned  the  procedures  of  language  control  ana 
defined  them  using  a  formal  modeling  technique  The 
resulting  models  promote  tight  administration  of  the 
control  function  by  exposing  the  details  of  all  tasAs  and 
forcing  attention  to  their  interrelationships  They  also 
provide  a  basis  'or  reconf igur ing  proven  Air  Force 
language  control  functions  for  Aoa.  and  the  ICF  has 
dentifled  some  important  considerations  in  accon^l ishing 
this  The  Air  Force's  transition  to  Ada  has  a  high 
probability  of  success  because  of  their  experience  with 
UOVIAL.  their  systematic  evolution  and  fine-tuning  of 
language  control  procedures,  and  the  extensibility  of 
these  procedures  to  encompass  Ada  82/00/00  83At1i98 


UTTl  Integrated  CNI  avionics  logistics  constderat tons 

AUTH  A/HARRIS.  R  L..  6/MCMANU<'  J  C  PAA  A/(USAF 

Avionics  Laboratory.  Wright-Patterson  AFB.  Oh).  6/(USAF 
Human  Resources  Laboratory,  Wright-Patterson  AFB  OH) 

In  NAECON  1982  Proceedings  of  the  Nattona*  Aerospace  and 
Electronics  Conference.  Dayton  OH,  May  18-20.  1982 
Volume  2  (A83-t1083  01-01)  New  York,  Institute  of 

Electrical  and  Elect^'orncs  Engineers.  Inc  1932.  p 
€43-650 

ABS  The  Integrated  Comhrunicatlon  Navigation  Identification 
Avionics  (ICNIA)  program  Is  an  advanceo  development 
program  which  Includes  logistics  support  criteria  into  its 
conceptual  design  and  system  aefinttioi  Some  key 
logistics  considerations  o*  ICNiA  are  discussed  including 
the  integration  of  a  number  of  avionic  systems,  the 
development  of  specifications  for  an  integrated  CNI 
Evaluator  and  a  series  of  logistics  analysis  studies 
Advanced  and  new  tacnnologies  employed  in  ICNIA  will  make 
possible  a  reduction  of  the  number  of  systems  through  the 
development  of  a  single  tntegraole  reconf igurable  system 
These  features  lead  to  expectations  of  major  savings  in 
voluma,  weight,  and  life  Cycle  costs,  as  well  as  an 
improvement  in  system  readiness  82/00/00  83A11157 


UTTL  ICNIA  -  Lessors  learned  on  sensor  integration 
AUTH  A/HAMMC,  0  L  PAA  A/(USAF.  Vrignt  Awronautica) 

Laboratories.  Wrtgnt-Patterson  AFB.  OH)  In  NAECON  1982. 
Proceedings  of  the  National  Aerospace  and  Electronics 
Conference.  Oayton,  OH.  May  18-20.  1982  Volume  i 
(A83-11083  01*01)  New  York.  Institute  of  Electrical  and 
Electronics  Engineers.  Inc  .  1982  p  93*97 
ABS  Integration,  at  several  levels,  appears  to  ba  a  fruitful 
eor>cept  *or  addressing  avionics  problems  at  both 
macroscvwic  and  microscopic  levels  Tnis  paper  addresses 
some  of  the  necessary  attributes  of  system  integration 
afforts  and  associated  problems  in  winning  acceptance  of 
integration  concepts  from  a  management  viewpoint  It  is 
Illustrated  by  reference  to  the  Integrated  Communication 
Navigation  ident 1 f icat ion  Avionics  (ICNIA)  program  which 
is  tracad  from  its  inMiai  coocsot  through  approval  to 
become  one  of  the  first  Air  Force  programs  with  the 
primary  Objective  cf  functionally  integrating  a  subset  of 
sensor  avionics  The  discussion  cover%  lessons  learned 
from  proposing  and  defending  the  philosophy  of  integration 
which  ultimately  resulted  <n  this  major  advanced 
development  program  within  the  Avionics  Laboratory  It 
offers  «n  insight  into  tyste  and  techncicgy  challenges  for 
the  coming  decede  82/OO/Oh  83A11096 


UTTL  F/A*18  Hornet  reliability  Challenge  -  Status  report 
AUTH  A/RICKETTS.  M  P  PAA  A/(McOonnen  At.  craft  Co  .  St 
Louis,  MO)  In  Annual  Reliability  and  Maintalnabi 1 l ty 
Symposium,  Los  Angeles,  CA.  January  26*28.  1962 
Proceedings  (A82-42176  21*38)  New  York,  Institute  Of 
Electrical  and  Electronics  Engineers.  i962.  p  491*496 
ABS  A  development  status  report  is  given  for  the  f/A-18  Hornet 
Reliability  Program,  in  which  an  attempt  is  made  to  give 
reliability  criteria  the  same  design  emphasis  as  weight 
performance  and  cost  Among  the  established  reliability 
assurance  techniques  applied  are  periodic  status 
assessments  for  each  subsystem  manager,  failure  mode  and 
affects  analysoa,  an  approved  parts  list,  selective  use  of 
Sneak  Circuit  Analysis,  and  a  closed  loop  evniuat'on  and 
raporting  system  which  reports  s<>d  tracks  all  equipment 
failures,  The  F/A-I8's  3  7-.>our  mean  fUgnt  timd  between 
failures  (MFT6F)  requirement  was  test<.*d  m  50  Reliability 
Oemorstrst ion  fllghte,  end  an  8  4*hour  MFTBF  was 
demonstrated  The  F/A-IB  inco< porates  such  high  inherent 
reliability  design  components  as  solid  state  avionics 
improved  avionics  cioling,  a  f ixed-geome*ry  engine  sir 
inlet,  simpler  hydraulics,  and  the  highly  simplified  F404 
engine  82/00/00  82A42229 


UTTL  R/M/lCC  effects  of  commereiai  off-the-shelf 
equipment 

AUTH  A/MACDIARMIO.  P.  R  ,  B/PETTINATO.  A.  0  C/jOHN$ON.  6 
a  PAA  B/(U<AF,  Some  Air  Development  Center.  Grifflss 
AFB.  NY).  C/(Rockwelt  Interne t lonal  Corp  Cedar  Rapids. 
lA)  In  Anrxjal  Reliability  and  Ms inta msbi  1  ity 
Symposium,  loS  Angelex,  CA,  Uanu.'try  26*26,  1982. 
.roceedings  (182*42176  2('38)  New  York,  Institute  of 
Electrical  and  Electronics  Engineers.  1982.  p  40*46 

ABS  This  paper  addresses  the  effects  or  using  wonmercial 
Off*the*ahe’f  equipment  in  military  wnyir 
Comparisons  are  tLsde  of  ni.itary  vs  commercial  reliability 
approaches  and  an  analytical  aporoach  for  choosing  the 
most  eppropriate  acquisition  strategy  is  i>‘eaented  Life 
cycle  cost  comparisons  are  made  of  commercial 
off -the*shelf  equipment  vs  similar  irilitartxed  equipment 
in  military  environments  Examples  are  presented  of 


assessing  risks  under  varying  applications  and  choosing 
the  best  acquisition  strategy  82/00/00  82A42181 


UTTl  Simple  vs  sophisticated  TacAir  avionics  II  • 

Soviet  TacAir  avionics  technology 

AUTH  A/BU$S£RT,  j  Military  E I ec trohics/Counterneasures .  vOl 
8.  Ma«  1982  p  56-62 

A8S  An  historical  study  is  presented  of  Soviet  tactical 

aircraft  avionics  developments,  encompassing  radars.  ECM 
ordnance  communications  and  cockpit  instrumentation  It 
IS  noted  that  (i)  there  has  been  a  marked  shift  since  1970 
from  Interceptor  to  ground  support  aircraft  development 
and  production,  (2)  that  ostensibly  obsolete  electronics 
such  as  the  MiG*25  vacuum  tube-based  Foxfire  radar  may 
exploit  low  vulnerability  and  exceptionally  high  power 
levels  and  (3)  that  the  simplicity  of  Soviet  avionics 
design  imposes  s  lower  acquisition  and  maintenance  cost 
burden  while  increasing  reliability  and  the  trainability 
of  news  It  IS  suggested  that  the  Soviet  study  of  F-14 
Phu  IX  miss'le  systems  since  the  Iranian  revolution  has 
been  'istrumental  in  the  development  of  a  MlG-25  two-seat 
variant  with  anti-cruise  missile  lOOk  down/shoot  down 
capabil'ty  82/03/00  82128397 


UTTL  The  modular  ATE 

AUTH  A/LCVY,  E  1  PAA  A/(Eastern  Air  Lines,  Inc  Miami 

«L)  In  AUTOTESTCON  '80,  Interna t i onal  Automatic  Testing 
Conference,  Washington,  DC  November  2-5.  1980 
Proceedings  (482-27876  12-59)  New  York,  Institute  of 
Electrical  and  Electronics  Engineers.  Inc  ,  1980  p 
M-53 

ABS  The  Eastern  Air  Lines  concept  of  modular  ATE  is  presented, 
with  attention  given  to  both  hardware  and  software 
aspects  Existing  maintenanco  philosophies  and  the 
classical  ATE  are  revlawed  to  show  why  present  concepts 
are  no  longer  cost  effective  Potential  problems  of  the 
modular  ATE  concept  are  examined,  and  the  need  for  further 
standardization  and  close  industry  cooperation  i$ 
discussed  80/00/00  82A278S6 


uTTl  Airline  ATE  requirements 

.UTH  A/HARMON,  H  E  PAA  A/(American  Airlines,  Inc  ,  Dallas 
TX)  In  AUTOTESTCON  '80.  Jnternat lone*  Automatic  Testing 
Conference.  Washington.  DC  November  2-5  1980. 

Proceeding'*  (482-27876  12*59)  New  York,  Institute  of 
Electrical  ana  Electronics  Engineers,  Inc  .  1980  p 
43-46 

ABS  The  general  requiremehts  of  airline  ATE  (automatic  tes' 
equipment)  are  reviewed,  and  attention  is  given  to 
cMdicated  modular  general -purpose  and  circuit  card  ATE 
It  IS  noted  that  mAintenarce  of  ali-oigttal  avonics  will 
require  the  full  utilization  of  standardized  instrument 
techniques  ana  the  atlas  test  language  to  accomplish  cost 
effective  tasting  and  repair  And  it  is  recommended  that 
airlines  effectively  communicate  these  test  tquiprr.ent 
requirerjents  to  the  suppliers  of  future  avionics 
equipment  60/00/00  82A27884 


UTTL  The  use  of  dynamic  mock-ups  in  the  'Jesign  of 
advanced  systems 

AUTH  A/CRAVELY.  H  L  B/HITCHCOCK.  L  PAA  A/(USAF  fl’gnt 
Dynamics  Laborstory.  Wnght-f'attersoh  AFB.  0M>  B/(U  5 
Naval  Material  Command,  Naval  Fir  De/eiopment  Cenior, 
Warminster  PA*  in  Human  Factors  Society.  Annual 
Meeting  24th.  Los  Angeles.  CA.  October  13*17,  1980. 
Proceedings  (182-22901  09-54)  Sants  Monica,  CA  Human 
Factors  Society,  Inc  1980.  P  5-8 

ABS  The  advantages  of  using  dynamic  mock-ups  in  advanced 

system  design  are  discussed  m  terms  of  the  USAf's  Digital 
Avionic  Information  System  (DAIS)  Program  and  the  Navy’s 
Advanced  Integrated  Display  System  (AIDS)  Cockpit 
Development  Program  Experienced  pilots  are  employed  to 
;udge  ti.e  acceptability  slide  pro«ector  displays  for 
radar  low-light  level  television,  a.id  alphanumeric  and 
vecto'  graphic  formats  Cost  effectiveness  is  achieved  by 
lowering  softwa'^e  costs,  minimizing  time  in  constructing 
the  mock-up.  and  high  rel labH i ty- low  maintenance 
features  The  cockpit  layout  is  set  up  once  the  required 
tasks  and  the  number  of  nul t i f unct ion  cort.ols  are  known, 
and  variations  on  the  instrumentat ion  set-up  are  tested 
repeatedly  The  AIDS  concept  allows  remote  location  of  a 
slide  projector  for  rlosed  circuit  television  display  of 
various  instrument  configurations  In  different  situations, 
and  selected  displays  are  chosen  for  full  scale 
simulation  80/00/00  82A22902 


jtTl  Very  high  speed  integrated  circuits  Into  the  second 
generation  II  «  Entering  Phase  1 

AUTH  A/MARTIN,  J  PAA  A/(Natidnal  Stm i cor^uctor  Corp  ,  Sants 
Clara.  CA)  Military  Electronici/Countermeasures.  voi  8. 
Oan  1982  n  60-63.  65,  66 

ABS  The  intended  applications  of  the  very  High  Speed 

Integrated  Circuits  (VHSIC)  chips  and  technologies  fall 
into  four  basic  categories  These  categcrias  are  ralated 
to  Current  operational  8''ste'*s  which  could  ba  improved 
through  VHSIC  technologies  without  change  in  performance, 
the  addition  of  new  performance  features  to  existing 
systems,  planned  upgrades  of  existing  systems  through  the 
use  of  VHSIC  technologies  and  new  systess  whicn  could  not 
dwvw.vpwu  wttr>out  tne  use  of  vhsic  tccnnology 
Attention  is  given  to  system  design  evolution,  aspects  of 
technology  inse-tton.  advantages  related  to 
stanaardizet Ion,  applications  ralated  to  the  development 
of  tne  next  generation  Advance  Tactical  Fighter  aircreft. 
the  improvement  of  reliability,  and  technology  transfer 
tesuas  82/01/00  82A21648 


B-7 


— » 


UTTl  Trends  Jn  ma t ntainaOt H ty  and  leltability  of 
avionics  systems  with  particular  reference  to  OCAO 
Technical  Publication  1/77 

AUTH  A/LOv,  A  F  PAA  A/{Ministry  of  Defence  /Procurement 
Executive/,  London  England)  lEE  Proceedings.  Part  F  - 
Communications,  Oadar  and  Signal  Processing,  vol  123,  pt 
f.  no  7  Dec  1981.  p  413-439 

4BS  The  procurement  situation  with  respect  to  reliability  and 
maintainability  (R&M);  prior  to  the  DCAD  Technical 
Publication  1/77  (1978)  's  reviewed  first  The  general 
contents  of  the  document  and  the  translation  of  the 
document's  principles  into  a  form  suitable  for  contracts 
are  then  discussed  Application  of  the  publication  1* 
outlined  and  an  indication  is  given  of  the  directio,  ft&M 
activity  should  proceed  m  order  to  meet  the  challenges  of 
future  systems  Particular  attention  is  given  to  the 
reliability  parameter  which  has  presented  a  more  serious 
problem  during  the  design,  development  and  pi-oductlon 
phases  81/12/00  82A16561 


UTTL  Balancing  readiness  and  life-cycle  cost  objectives 
in  avionics  acquisition 

AUTH  A/CALVO.  A  B  8/KRQNENfELD  0  E  PAA  B/lAnaiytic 
Sciences  Corp  ,  Reading,  MA )  In  NAECON  1981 
Proceedifigs  of  th*  National  Aerospace  and  E lectroiiics 
Conference.  Dayton.  OH  May,  19-21,  I98i  volume  2 
(A81:-l4€76  04-01)  New  York,  Institute  of  Electrical  and 
Electronics  Engineers  Inc  1981.  p  391-697 

ABS  Life-cycle  ccst/readiness  analysis  methods  and  issues 
emerging  In  studies  conducted  at  TASC  are  discussed  m 
order  to  establish  a  balance  between  life-cycle  cost 
requirements  Ou''ing  peacetime  conditions  and  operational 
readiness  needs  m  wartime  employment  Specific  areas 
which  provide  a  oasts  for  the  design  team  are  rrviewed. 
including  assessment  of  logistic  support  impacts  the 
Identification  of  principle  system  design  pararfteters  and 
exploration  of  tradeoffs  on  investment  options  In 
addition,  recommendat ions  on  incorporating  the  analysis 
efforts  in  the  systems  acquisition  planning  process  a'^e 
offered  8I/00/OO  92414785 


UTTL  Reusable  ai>  >u*(cs  executive  software 

AUTH  A/80LISLEV.  R  f  PAA  A/( Boe ing  M 1 1 1  tary  A 1  rp lane  Co  . 
Seattle.  WA )  m  NAECON  1981  Proceedings  of  the 
National  Aerospace  and  Electronics  Conference  Dayton  Oh, 
May  19-21.  1981  Volume  1  (A82-14676  04  OD  New  York. 

Institute  of  Electrical  ana  Electronics  Engineers  Inc 
1901,  p  31-36 

ABS  forecasts  indicate  that  avionics  architecture  will  evolve 
from  Single  multiplex  to  hierarchical  multiple  multiple* 
archi tectures  Tne  uSAf  0IA$  program  ‘s  developing  a 
common  modu'ar  reusable  executive  computer  program  m 
order  to  minimise  the  cost  of  executive  software  in  future 
avionics  Systems  The  key  to  the  concept  of  a  modular 
reusable  executive  is  the  defmit-on  of  the  functional 
modules  within  the  executue  anu  a  rigujiy  enforced 
interface  between  trie  functiorai  modules  An  executive  foi 
an  avionics  apulicatiwn  consists  of  two  major  functions 
(1)  a  bus  control  for  ir,«racting  to  a  data  transfer 
medium  and  for  controlling  this  meotwm  and  (2)  a  local 
control  for  executive  functions  which  are  local  to  trio 
processing  element  A  proposed  hierarchical  avionics 
architecture,  and  the  executive  corf  ig^it  at  ion  and 
functional  module  are  'llustrated  81/00/00  02A14681 


UTTL  Software  documentation  •  The  lifeline  of  ccmputer 
programs 

AUTm  A/king.  $  H  S/POTTS  0  H  PAA  A/ICeneral  Dynamics 
Corp  ,  fort  worth  Ta)  O/tSHP  Development  Co  Redwood 
City.  CA)  In  Digital  Avionics  Systems  Confer enco  4th. 
St  Louis  MO  November  t7-i9.  1981  Collection  of 
Technical  Papers  (A82-13451  03-04)  N«>w  York  American 
Institute  of  eronautics  and  Astronaut ics .  1981  p 
181  - 187 

ABS  Guidelines  for  determining  software  documentat *on  needs 
and  methods  of  imoi ementat ion  are  presented  Topics 
discussed  include  the  purposes  uf  software  documentation, 
documentat Ion  type*  and  scope,  the  use  of  software 
documentation  for  management  control,  and  a  recommended 
documentat ion  procedure  It  is  ompnasized  that  good 
documentation  provides  ’ha  means  for  successful  software 
integration  in  prr'pent  and  future  aircraft 

RPT*  AIAA  81-2255  81/00/00  82At3476 


UTTl  mil-STD  1750  Chip  set  Possipio  designs 
AUTH  A/LYNN  H  C  B/MOORE  fl  K  PAA  8/(Generol  Oviomics 
Corp  ,  Fort  Worth  Tx)  In  Digital  Avionics  Systems 
Conference,  4th.  St  Louis  MO  November  17-19,  1981 
Collection  of  Technical  Papers  fA82-l345l  OB-Oa)  New 


St  Louis  MO  November  17-19  1981,  Collection  of 

Technical  Papers  (A82-13451  03-04)  New  Vor'  Ameriran 
Institute  of  Aeronautics  and  Astronautics.  I98i,  p 
163- 167 

ABS  The  issue  of  malntabllity  of  avionics  components  is 

discussed  with  particular  leference  to  problems  currently 
seen  within  the  logistical  support  syitem  Particular 
attention  is  given  to  nonstandard  specifications, 
prol 1 ferat Ion  of  part  numbers,  the  problem  of  product 
obsolescence  and  the  problem  of  diminishing  manufacturing 
sources  It  is  shown  that  standardization  is  essential  for 
the  long-term  .viability  of  the  defense  structure 

RPT-r  AIAA  81-2252  01/00/00  82A13473 


OTTl  Variable  speed  constant  frequency  /VSCF'  eiertrica' 
system  cuts  cost  of  ownership 

AUTH  A/HILOEBRANT ,  K  V  B/VANNOCKEfi.  R  C  PAA  B/(General 
Electric  Co  Aircraft  Equipment  Div  .  Binghamton.  NY) 

In  InLersoc let y  Energy  Conversion  Engineering  Conference 
16th  Atlanta,  GA.  August  9-14,  1981  Proceedings  Volume 
1  (A82  1*701  02-44)  New  Yom .  American  Society  nf 

Mechanical  Engineers  19S1.  p  130-135 

AOS  The  methodology  employed  in  the  development  of  the 

electrical  generating  system  for  the  f/A-l8  aircraft  is 
considered  This  system  was  the  first  production 
application  in  which  the  cycloconverter  electronics  were 
packaged  with  the  generator  and  mounted  directly  to  the 
accessory  gearpox  Being  the  first  production  system  of 
this  type  a  detailed  and  comprehensive  analysis  and 
evaluation  program  was  undertaken  to  provide  assurance 
that  the  design  could  operate  with  a  hfgh  degree  of 
reliability  m  this  generally  hostile  environment  A 
primary  ma  inta 1  nab  1 1  1 ty  design  objective  was  related  to 
the  design  and  the  select'on  of  parts  and  materials  which 
would  last  for  the  life  of  the  unit  without  scheduled 
maintenance  Attention  is  given  to  maintenance  cost 
experience  and  life  cycle  cos*s  01/00/00  82Aii7l9 


UTTl  Closed  loop  env  1  ronmenta  1  control  system-,  for 
fighter  aircraft 

\UTH  A/TSUOIKAWA,  C  5  B/RAJPAUL  V  K  PAA  B/(Boe»ng 

Military  Airplane  Co  .  Seattle.  WA)  American  Society  of 

Mechanical  Engineers,  Intersociety  Conference  on 
Cnvf ronmental  Systems.  San  Francisco  CA.  July  13-15 
1981.  6  P  USAF -sponsored  research 

ABS  A  favorable  thermal  environment  for  aircraft  avionics 

implemented  m  an  energy  efficient  manner  is  an  important 
factor  in  reducing  aircraft  life  cycle  costs  through 
improved  avionic  reliability  This  paper  discusses  the 
application  of  clo*o0  loop  environmental  control  systems 
1CECS)  to  a  tactical  mission  aircraft  Tne  specific 
Objective  was  to  determine  CECS  configurations  which  would 
piovide  significant  savings  in  fuel  consufiption  and  I'fo 
Cycle  costs  while  maintaining  stable  low  temperature 
clean  and  Ory  envifOi>mant  for  avionics  equipment 
Preliminary  designs  were  develspec  for  a  positive 
displacement  rotary  vaned  air  cycle  machine  systen  hybrid 
air/vapor  cycle  system  centrifuga’  Freon  compressor  vapor 
cycle  system  and  a  turDO*mach 1 nery  air  cycle  machine 
System  System  characteristics,  details  of  design 
perforr*ance  and  i<fe  cycle  cost  data  were  compared  with  an 
existing  open  loop  air  cycle  system  The  study  snowed  that 
dosed  loop  System  configurations  ana  close  avionic 
temperature  control  resulted  in  substaritial  life  Cycle 
cost  savings 

9Pf»  ASME  PAPER  81-ENAS-2  81/07/00  &2A10890 


UTTl  Atrcraft/avionics  environmental  mtegratiijn  program 
AUTH  4/hERMES  P  B/WAFFORO  J  PAA  B/(USAF  Aeronautical 
Systems  Olv  .  wr ight -Pat terson  AF6,  OH)  In  Life  Cycle 
oroo'ems  and  env 1 ronmental  technology,  Proceedings  of  the 
Twenty-sixth  Annual  Technical  Meeting  Philadeiph'a  PA, 
M<.y  t2-l4.  1980  (A81-46476  22-38)  Mt  PrOspOCt.  IL, 

Institute  of  Environmental  Sciences  1980  p  23-27 
ABS  Activities  of  USAF/Aeronaut lea  1  Systems  Division  related 
to  air craf t/av ion  ICS  environmental  integration  aro 
reviewed  with  emphasis  on  specifications  and  standards 
being  developed  to  assist  in  acquiring  equipments  and 
Systems  'n  a  cost  effective  manner  The  primary  purposes 
of  these  documents  are  (i)  to  introduce  new  analyses  and 
tradeofi  studies  m  the  early  development  phases,  (2)  to 
provide  a  contractual  basis  for  informal  activities 
previously  accomplished  by  the  contractors,  and  (3)  to 
-eplaco  o-  Supplement  universal  requirements  with 
engineering  approaches  tailored  to  specific  applications 
80/00/00  81A46480 


RPT» 


AUTM 


York  American  Institute  of  Aeronautics  and  Astronaut ics, 
1981.  p  160  172 

Tne  development  of  a  mil -STO- 1750A  compliant 
microprorossor  chip  set  for  use  In  digital  avionics 
systems  13  presented  Design  constraints  are  identified 
and  a  logical  partitioning  of  me  chip  s^t  is  defined 
Signal  interfaces  Are  proposed,  and  potential  physical 
conf fgurat ions  for  the  chip  set  are  presented  The  cost  o' 
miniatur 1 zat ion  is  found  to  be  high,  although  with  user 
discretion  in  implementing  the  instruction  set 
Srch  ‘octw'C  wTr.lw  »/<  uw  iii  irtg  aa  mucn  capability 

as  possible,  a  mIL-STO- 1750A  compliant  microprocessor  chip 
set  with  wide  user  acceptance  can  be  produced 
AIAA  81-225'J  gl/00/00  82A13474- 


JTTI  Avionics  component  stai  oardi zat ion  -  The  key  to 
ma  tnta  inao  1 '  1  ty, 

A/MARTIn  J  PAA  A/(Tiat  tonal  Semiconductor  Corp  Santa 
Clara  CA )  In  Digital  Avionics  Systems  Conference  4th. 


UTTL  Av'orlcs  thermal  integration  for  the  Boeing  767 
airplane 

AUTH  A/$LAc<,  R  L  .  B/LLOyO  A  J  P  PAA  8/(8oeing 

Commercial  Airplane  Co  ,  Renton.  WA )  in  Life  cydo 
problems  and  environmental  technology.  Proceedings  of  the 
Twenty-sixth  Annuel  Technical  Meeting  Philadelphia  PA 
May  12-14,  1980  {A81-46476  22-38)  Mt  Prospect  IL, 

Institute  Of  Env 1 ronmer tal  Sciences  1980  p  11-18 

ACS  wiTh  reference  to  Boemcj  aircraft  B-747  ann  r.-a? 

used  to  iwprove  aviomc  reliability  and  reduce  maintenance 
costs  by  lowering  component  operating  temperatures  are 
discussed  Attention  is  given  to  the  following  cooling 
concepts  (1)  av'onic  cooling  air  exhausted  overboard 
after  cooling  avionics,  (2)  avionic  cooling  air  recooted 
using  ram  aif,  (3)  avtomc  cooling  air  recooled  using  air 
conditioniiig  system  an;*  (4)  avionic  cooling  air  recooled 
using  Skin  heat  exthanje  A  prototype  avionic  cooling 
Sys’om  for  the  B-7()7  which  emplOyS  8  skin  boat  excfianger 
is  presented  80/00/00  81A46478 
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UTTL  O&IS  controls  and  displays  ‘  A  systen>5  approarh  to 
avionics  soPsystew  integration 

AUTH  A/BROWr'l  G  W  B/GARChER  J  0  PAA  B/(USAr,  Avionics 
laboratory,  Wr Ignt-Patterson  AF8  Ohio)  in  NAECON  1980 
Proceedings  of  the  National  Aerospace  and  Electronics 
Conference  Oayton  Oh»o,  May  20-J2  1080  Volwne  3 

(A81-30226  12*04)  New  Vork  Institute  of  Electrical  and 
Electronics  Engineers  Inc  1980,  p  1057-1064 

ABS  The  increasing  complexity  of  U  S  Aw  force  aircraft 
mission  requirements  and  the  rvecessity  for  reducing 
avionic  life  cycle  costs  require  a  total  systems  approach 
to  future  avionic  subsystem  integration  The  Digital 
Avionics  Information  System  Controls  and  Displays  (C/0)  is 
an  integrated  subsystem  that  utilizes  specific  pilot 
control  procedures  and  common  communication  techniques  to 
accomplish  virtually  alt  avionic  functions  with  the  same 
pilot  C/0  hardware  This  paper  discusses  the  system  design 
approach  needed  during  avionics  development  process  to 
achieve  an  integrated  C/0  subsystem  Empnasis  is  placed  on 
interaction  between  pilot  procedures  mission  operations, 
and  C/0  subsystem  and  related  interfaces  The 
reconf igurat ion  capabilities,  the  esse  of  incorporating 
new  avionic  functions  and  other  benefits  derived  from 
common  C/0  hardware  are  also  addressed  Finally  critical 
issues  facing  C/0  such  as  pilot  workload  acceptance'  by 
the  avionic  community  of  new  control  and  display 
techniques,  degree  of  display  device  coisplexity  and  C/0 
areas  amenable  to  standard! zat ton  are  examined  80/00/00 
81A30336 


UTTL  Tailoring  software  logic  to  the  needs  of  the  pilot  - 
A  software  designer's  nigntmare 

AUTH  A/MURRA>  j  8/RElSlNG  d  PAA  A/(System  Consultants 
.nc  Oayton,  Ohio)  8/{USAF  flight  Dynamics  Laboratory 
Wr ignt-Patterson  AFB  Ohio)  In  NAECON  i980  Proceedings 
of  the  National  Aerospace  and  Electronics  Conference 
Oayton  Ohio,  May  20-22.  1980  volume  3  (A8t-30226  12-04) 

New  York  Institute  of  Electrical  and  Electronics 
Engineers  Inc  1980  0  1052-1056 

ABS  Digital  avionics  and  multifunction  displays  ana  controls 
are  being  incorporated  into  aircraft  of  tne  Air  force. 

Navy  and  Army  with  increasingly  greater  frequency  One  of 
the  key  aspects  in  their  acceptance  and  usefulness  is  the 
design  of  the  software  so  that  it  supports  the  needs  of 
the  user,  speciftcally.  the  pilot  8y  tailoring  the 
software  such  that  display  formats  and  multifunction 
control  logic  are  custom-designed  to  appropriate  mission 
phases,  a  reduction  in  pilot  workload  is  accomplished  A 
senes  of  studies  have  been  conducted  examining  this 
reduction  m  pilot  workload  by  employing  Tailored 
Multifunction  Control  Logic  versus  standard  Branching 
Control  Logic  A  Significant  improvement  in  pilot 
performance  has  resulted  from  the  use  of  Tailored  Logic 
However,  in  an  era  of  ever  increasing  software  costs,  the 
benefits  to  the  pilot  need  to  be  weighed  against  the  costs 
of  ifiplomentirg  this  tailored  software  80/00/00 
81A3033S 


UTTl  An  analysis  of  the  common  Multi-Mode  Radar  Prog* am 
using  the  Standardizat ion  Evaluation  Program 

AUTH  a/Thomas  j  l  s/uolOa  j  g  paa  e/(uSAF 

Wright-Patterson  AFB.  Ohio)  In  NAECON  1980.  Proceedings 
of  the  National  Aerospace  ana  Electronics  Conference. 
Oayton,  Ohio,  May  20*22  1900  Volume  2  (A81-30226  12-04) 

New  York  Institute  of  Electrical  and  Electronics 
Engineers,  Inc  1980,  p  839-845 

ABS  The  cost  impact  of  s tandard izat ion  as  applied  to  Air  Force 
avionic  systems  is  discussed  in  this  paper  Several  I'fe 
cycle  cost  estimates  were  made  on  the  A$0  Common 
Multi-Mode  Radar  Program  using  t>>e  Stanoai  dizat  ton 
Evaluation  Program  (STEP)  model  Costs  for  development 
operation,  and  Support  of  a  common  (standard)  radar  system 
arc  compared  with  like  costs  estimated  for  using 
individually  developed  radar  systems  across  applicable 
aircraft  STEP  estinates  project  I'fe  Cyde  costs  of 
unique  radar  systems  to  be  twice  those  of  a  common  radar 
system  Results  are  discussed  m  terms  of  STEP  runs  and 
ASP  costing  estimates,  and  STEP  model  use  i$  described 
80/00/00  81A30318 


UTTL  Automated  Requirements  Oovelopment  System 

AUTH  A/HA2LE.  M  B/GlENN  U  S  PAA  B/(Mltre  Corp 

Bedford,  Mass  )  In  NAECON  1980  Proceedings  of  the 
National  Aerospace  and  Electronics  Conference  Oayton 
Ohio  May  20-22.  1980  volume  1  (A8t'30226  12-04)  New 

York,  Institute  of  Electrical  and  Electronics  Engineers 
Inc  1980.  P  435-439 

ABS  The  Automated  Requirements  Development  System  (ARCS)  is  a 
set  of  software  tools  supporting  requirements  for  the 
development  activities  of  the  Air  Force  Electronics  System 
Jivijion  (ESO)  program  office  for  large  weapons  systems 
The  activities  are  spec  i  f  teat  ic.n  generation,  review, 
revision  and  analysts  and  requirements  tracing  4R0S 
functional  rapeoi 1 i t les  include  document  generation  and 
ma in*s<iance,  comment  management,  document  analysis  and 
remote  tool  interface  ARPS  data  include  outlines 
standard  parag'-aphs  standard  terms  and  definitions 
checklists,  guidelines,  and  specification  samples 
80/00'00  81A30276 


UTTL  Using  microprocessors  in  fault  monitoring  of 
aircraft  electronics 

ajTm  A/mayBANKS,  a  paa  A/(Ultra  Electronic  Controls  Ltd  . 
Londor.  England)  American  Society  of  Mechanical 
Engineers.  Gas  Turbine  Conference  and  Products  Snow 
Houston  Tox  ,  Mar  9*12.  1981,  5  p 


ABS  The  Ultra  Electronic  Controls  fault  Ident i f icat i on  Module 
as  used  in  the  Flectromc*  Engine  Control  Unit  (ECU)  for 
the  Olympus  593  engines  of  the  Concorde  Supersonic 
Transport  Aircraft  is  oiscussod  This  is  based  on  a  CMOS 
microprocessor  fc'  m*.  power  consumption  and  encibles  the 
module  to  bo  applied  to  e'-isting  units  without  redesign  of 
power  supplies  The  module  examines  the  outputs  ;f 
existing  fault  monitoring  circuits  and  compares  these  with 
sof tware-def ined  reference  levels  It  then  determines 
fiom  this  and  other  signals  taken  from  the  ECU  safety 
consolidation  circuits  the  engine  control  subsystem  which 
IS  at  fault  This  module  has  been  in  service  for  close  to 
one  year  now  and  the  mpact  on  rapid  and  accurate  fault 
diagnosis,  eliminatior  of  premature  ECU  removals  and  thus 
reduction  of  cost  ownership  of  the  ECU  is  discussed 
rtPT»  ASME  PAPER  81  CT  138  81/03/00  81A30040 


uTTl  Avionic  archi tactura I  s tandarji za t i on  -  Logistic 
support  perspect Ive 

AUTH  A/MA50N  R  C  B/PARRIOTT  L  0  PAA  B/(TRW  Defense 
and  Space  Systems  Crni<p,  Redondo  Beach,  Calif  )  In 
Standard  I zat 'on  in  military  avionics  systems  architecture 
Proceedings  of  the  Seminar,  Oayton  Ohio  Novembei  28 
1979  <A31-13167  03-04)  New  York  Institute  of  Electrical 

and  Electronics  Engineers,  Inc  .  1979,  p  27-34 

ABS  The  advent  of  digital  technology,  speciftcally  embedded 

computer  systems  (ECS)  has  provided  the  impetus  for  rapid 
growth  m  the  sophistication  and  complexity  of  airborne 
information  processing  functions  Along  with  the  growih  in 
avionic  systems  soph t s t ica t ion,  there  has  been  a 
corresponding  increase  in  tneir  costs  and  a  proi  iferat  ion 
of  unique  computor-embedded  avionic  systems  and 
subsystems  This  influx  of  embedded  computer  systems  has 
introduced  a  new  approach  to  the  management  and  support  of 
avionics  systems  at  air  logistics  centers  This  paper  will 
describe  this  avionic  support  approach  This  paper  takes  a 
closer  look  at  the  problem  created  by  the  rapid  influx  of 
embedded  computer  systems  each  with  their  unique 
archi tectur es  for  current  and  planned  ECS  support  systems 
and  then  reflects  on  several  lessons  learned  and  discusses 
where  Doth  avionic  arch i tec tura I  standards  and  support 
facility  standards  can  nelp  reduce  the  pro l i ferat ion  of 
Support  systems  79/00/00  81A1J171 


UTTl  Cost  analyses  for  avionics  acquisition 

AUTH  A/T00H£y.  E  F  B/CALVO  A  S  PAA  8/(AnaIytiC 

Sciences  Corp  Reading  Mass  )  In  Annua)  ReiiaPility 
and  Ma  mta  mab  1 1  I  ty  Symposium  tan  Frarcisco  CaMf 
January  22-24  i980  Proceedings  (A80-40301  16*38)  New 

York,  Institute  Of  Etectncal  arid  Electronics  Engineers 
Inc  .  1980  p  85-90 

ABS  The  paper  reports  on  the  types  of  tost  reliability  ana 

maintenance  tradeoff  studies  of  cost  analyses  required  for 
formulating  an  effective  acquisition  strategy  Sample 
study  results  are  provided,  ana  a  description  o*  now  study 
results  are  used  to  focus  on  critical  issues  'n  the 
acduisition  proprars  is  provided  Tne  reliability  's  found 
to  be  a  ce'itral  factor  but  its  ultimate  effect  on  support 
costs  IS  deterpBinco  by  otner  influences  such  as  tne 
structure  and  efficiency  of  the  logistic  support  system, 
attention  must  be  directed  early  in  the  development  cycle 
to  Identifying  support  cost  drivers  w'thin  a  framework 
whicfi  accomodates  the  actual  equipment  use  and  support 
rond-tions  Once  tne  drivers  are  identified,  cost  control 
procedures  m  the  form  of  warranties  and  verification 
testing  which  focus  on  the  principal  areas  of  concern  can 
be  tntegratort  into  the  acdutsition  plan  80/00/00 
80A403n 


UTTl  Avionics  and  controls  technology  trends 

AUTH  A/5MYTH,  R  K  PAA  A/(MHco  International.  Inc 
H-jntingtOh  Beach  Calif  )  American  Institute  of 
Aeronautics  and  Astronaut ics,  International  Meeting  and 
Technical  Display  on  Global  Technology  2000  Baltimore 
MO  May  6-8,  1980,  13  p 

ABS  The  trends  which  will  define  the  state  of  the  art  in  the 
year  2000  for  aeronautics  avionics  and  controls  are 
eraorgmg  m  1980  The  prospective  of  the  last  three 
decades  of  avionics  and  controls  doveirypments  coupled  with 
the  current  technological  progress  in  very  large  scale 
integration  (/LSI)  microelectronic  circui's  provide  the 
oasis  for  the  projection  of  technology  trends  for  the  yi  •'r 
2000  The  paper  reviews  the  trends  in  broadly  applicable 
technologies  as  they  will  impact  the  aeronautic  vchiclo 
specific  technologies  during  the  next  two  decades 

RPT»  AIAA  PAPER  80-0919  80/05/00  80A32889 


uTTl  Issues  in  avionics  standardization 
AUTH  A/RICKER.  R  K  PAA  A/(U$AF.  Aeronautical  Systems  Oiv 
Wr  ight -Pat  terson  AFB  Ofilo)  In  Cha. tenge  of  th©  '80s, 
Proceedings  of  the  Third  Digital  Avionics  Systems 
Conference  Fort  Worth  Tex  ,  November  6-8,  1979 
(A80-J2417  12  06)  Now  York ,  Institute  Of  EloctrlcAl  ana 
Electronics  Engineers,  Inc  ,  1979.  p  240-243 
ABS  The  paper  defines  criteria  for  the  selection  of  avionics 

standardizat ion  factors  which  take  into  account  thr  forces 
which  determine  the  productivity  of  standardizat ion  These 
factors  Include  technological  maturity  and  archl tectura ! 
SMitwhiii*^,  ,iy  rautor  deals  with  a  subsystem 

where  the  majority  of  elements  are  in  a  thrae*year  CyCle 
of  ‘order  of  magnitude'  performance  requirements,  size 
reduction,  or  mecnanizat ion  changes  In  such  cases 
standard* zat ion  is  not  feasible,  if  the  subsystem  is 
archi tectura 1 1 y  interdependent  with  other  subsystems  with 
complex  interfaces  and  a  high  degree  of  software 
standaroi zat Ion  is  much  more  difficult  than  ‘n  a 
stand-alone  subsystem  with  simple  interfa  .  79/00/00 

8f >32450 
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•jTTi.  A  co»par»soA  of  computer  architectures  for  the  NASA 
aemoAsfjit  ton  advanced  avionics  system 

AUTH  A/SEACyKO  C  L  ,  B/BAIIEV.  t>  G  C/LARSON,  J  C 
PAA  C/^Honev'^en ,  Ii->C  ,  Avionics  Oiv  Minneapolis 
Minn  )  CORP  Honeiwe)*  Inr  Minneapolis  MN  In 
ChaUpnge  of  the  '80s  Proceedings  of  the  Third  Digital 
Avionics  Systems  ronfeience.  Fort  Woi th.  Te»  .  Novenoer 
6  8  1979  UeO-32417  U-0€)  New  Vork  Institute  of 

electrical  and  Electronics  Engineers.  Inc  .  1979,  p 
51-57 

A85  The  paper  compares  computer  architectures  for  the  NASA 
demonstration  advanced  avionics  system  Two  cci^uter 
archi tecturos  are  described  with  an  unusual  approach  to 
fault  tolerance  a  single  spare  processor  can  correct  for 
faults  in  any  of  the  distributed  processors  by  taking  on 
the  role  of  a  foiled  module  It  was  shown  the  system  must 
be  used  from  a  functional  point  of  view  to  properly  apply 
redundancy  and  achieve  fault  tolerance  ana  ultra 
reliability  Data  are  presented  on  compleKity  and  mission 
failure  probability  wnich  show  that  the  revised  version 
offers  equivalent  mission  reliability  at  lower  cost  as 
measured  by  hardware  and  software  complexity  79/00/00 
80A33427 


UTTL  Single  ch.p  custom  LSI  microcomputers  for  avionics 
appi icat ions 

AUTH  A/KANTOWSKl.  0  W  PAA  A/(Beridix  Corp  Avionics  Oiv 
Fort  Lauderdale,  Fla  >  In  Challenge  of  the  '80s 
Proceedings  of  the  Third  Digital  Avionics  Systems 
Conference  Fort  Worth  Tex  November  6-8  1079 

{A80-32417  12  0€ )  New  York.  Institute  of  Electrical  and 
Electronics  Engineers,  Inc  ,  1979  p  02-36 

ABS  The  paper  discusses  a  single  chip  custom  LS.  microcomputer 
with  flexible  architecture  and  a  variable  instruction  set 
This  device  was  developed  as  an  alternative  to  a  full 
custom  LSI  and  its  associated  long  lead  time  nigh 
development  cost  and  difficulties  in  incorporating 
changes  The  microcomputer  contains  all  the  cc-ruter 
elements  similar  to  MQSTEK  3870  it  is  much  m^re 
efficient,  the  iiarowired  logic  can  bo  included  on  the 
chip  and  its  costs  are  che«iper  than  standard  system 
implementations  Software  developraent  can  take  place  on 
existing  systems  using  macro  instruct  ions  and  can  be  fully 
debugged  in  its  application  system  using  a  simulator 
board  79/00/00  80A32423 


UTYl  Advancoo  aviomc  ar  chi  tecturos  for  the  1980's  -  A 
software  view 

AUTH  4/MORGAN  L  F  RAA  A/i I ocvheed  Ca 1 i f Orn la  Co 

Burbank  Caiif  )  In  Cnailerige  of  tne  '80s  '’roceedmgs 
of  *he  Third  Digital  Avionics  Systems  Conference  Fort 
Worth,  Te*  November  6-8  1979  (A80- 32417  12*061  Now 

York  Institute  Of  Electrical  and  Electronics  Engineers 
Inc  1979  0  13-18 

ABS  The  paoer  examines  advanced  avtunics  architectures 
including  'distributed'  and  'hierarchal'  with  a 
centra! lAea  mui t iprocessor  system  at  the  apex  It  was 
Shown  that  the  concept  of  distributed  computers  m 
avionics  has  been  earned  too  far  and  that  the  eventual 
impact  of  cheao'hol 'able  digital  hardware  in  avionics 
software  wilt  be  the  use  of  larger  numbers  of  CP  ano 
memory  elements  m  oedi'.ateo  and  snared  iiierarcnai 
archi teotures  The  aM  digital  character  and  requirements 
for  future  avionics  archi tectures  win  lead  to  a 
f I y-bef oro*spec 1 f y  policy  using  an  early 
total  svstem-simulat ton  approach  systems  development 
79/00/00  80A32420 


UTTL  wfLS  -  An  international  approach  to  range 
»nst-umentat ion  support 

AUTH  4/luSTina  w  P  PAA  Ay(RCA  Missile  and  Surface  Radar 
Div  ,  Moorestown,  N  U  )  RCA  Engineer  vol  25.  Feb  -Mar 
1980  D  41-46 

ABS  It  IS  noted  tha*  reliable  on-demand  operation  of 

precision  tracking  radars  is  a  key  element  in  Supporting 
critical  missions  on  today's  test  ranges  Such  raJars  are 
located  at  various  sites  around  the  world  which 
complicates  the  problem  of  keeping  tnem  eperatiof’ai  The 
paper  describes  an  interagency  approach  to  tne  problem, 
the  Worldwide  Engineering  and  Logistics  Support  (WELS) 
Program  Attention  is  given  to  the  scope  ano  operation  of 
the  program,  including  tn©  dive<sHy  of  range  user 
requirements  ano  tne  engineer mg/technical  assistance  and 
logistics  support  needed  80/03/00  80431249 


UTTL  ATE  system  acquisition  for  E-3A  sentry  /AWACS/ 

AUTH  A/QUNCAN  R  0  P  8/WlLSON,  J  H  ,  C/SCHELLEN8ACH  R 
R  PAA  A/(tiSAF  ESectronic  Systems  Oiv  .  Bedford 
Mass  ),  8/(U5AF  Warner  Robins  Air  logistics  Center 

Robins  AFB  Gj  ),  C/isipport  System  Associates.  Ir>c 
Burlington  Mass  )  m  AuTOTESTCON  '79  Proceedings  of 
the  Inter nat t ona 1  Automatic  Testing  Conference. 
Minneapolis,  Minn  September  l9-2l.  1979  (A80-2999I 

11-59)  Nrv  York,  institute  of  Electrical  and  Electronics 
Engineers,  Inc  1979,  p  365*369 
ABS  The  paper  describes  the  systems  engineering  and  management 
decisions  for  the  support  of  the  organic  depot  maintenance 
oonr^finn  nY  ♦»>«  £-34  Oc-.t.y  A.toiwft  in  oro©r  to  provide 
cost  effective  acquisition  of  ATE,  a  listing  is  yivei  of 
the  alternatives  and  considerations  required  to  fpe**  an 
overall  picture  of  the  technical  capability  and  total 
ownership  cost  of  a  particular  atc  system  Special 
attention  is  given  to  ATE  useful  life  req^nromenrs, 
efficiencie'  and  personnel  skill  level  The  methodology 
employed  m  sbpport  of  the  E-3A  mission  avionics  is 
considered  79/00/00  80A30033 


UTTL  F/A'18  Automatic  Test  Equipment 
AUTH  A/MAJOR  T  j  PAA  A/(L)  S  Naval  Air  Systems  Command. 
Washington.  DC)  In  AlJfOTESTCOtJ  '79,  Proceedings  of 
the  International  Automatic  Testing  Conference. 
Minneapolis.  Minn  ,  September  19-21,  1979  (A80-29991 

tl-59)  New  York,  Institute  of  Electrical  and  Electronics 
Engineers,  Inc  .  1979  p  317-319 
.  i$  The  development  of  the  F/A-18  Automatic  Test  Equipment  is 
discussed  Attention  is  given  to  areas  in  which  cost 
reduction  techniques  and  lessoiis  learned  from  past  ATE 
programs  have  been  implemented  Areas  covered  include  the 
F/A-18A  ILASS.  the  need  for  the  ATE  to  be  ship,  shore  and 
USMC  van  compatible,  systems  monitoring,  confidence 
testing  porformance  testing,  and  station  maintenance  and 
repair  Also  covered  are  the  Radar  Test  Station  (RTS)  and 
the  benefits  of  the  colorgraphic  dlsp)ay,  which  include 
the  possibility  for  ope''ato-  corrective  action  improved 
operator  efficiency  reduced  paper  documentation  currency 
of  documentat ion  and  automatic  test  generation 
79/00/00  80A30028 


UTTL  System  EMC  -  Tendencies  of  a  worldwide 
stanu  irdi rat  ion  and  cooperation 
AuTH  A/RODE  R  PAA  A/ { Messer schm 1 1 1 -Boe I kow-B 1 0hm  GmbH . 

Munich  West  Germany)  In  Electromagnetic  compatibility 
1979  Proceedings  of  the  Third  Symposium  and  Tecrmcal 
Exhibition  Rotterdam,  Netherlands  May  i-3  19'’9 

(A80-277S3  10*32)  Zurich.  E idgenoess t sche  Technische 
Hochschole  Zuer ich.  1979  p  485*490 
ABS  The  paper  deals  with  the  tendencies  in  worldwide  EMC 

standardi rat  ion  and  cooperation  Emphasis  is  placed  on 
standard! zat ion  of  test  methods  including  system  analyses, 
system  integration,  prototype  and  production  systems  EMC 
problems  in  an  1 ntornat lOnal  airport  and  military^  aircraft 
are  outlined  79/00/00  80A27784 


UTTl  An  i  itegrated  multi -System  approach  to  the  support 
of  digital  avionics 

AUTH  A/BABIAK,  N  U  B/PAwRIOTT.  L  0  ,  OR  PAA  A/(U5AF. 
Logistics  Command,  wr ight -Patterson  AFB,  Ohio),  B/(TRw 
Defense  and  Space  Systems  Group,  Redondo  Beach.  Calif  ) 

In  NAECON  1979,  Proceedings  of  the  National  Aerospace  and 
Electronics  Conference  Daytor.  Ohio  Hay  15-17  1979 

volume  2  {A79-48690  21-01)  New  York,  Institute  of 

EJectncai  and  Electronics  Engineers,  Inc  1979  p 
544-649 

A6S  Tne  paper  examinfs  existing  aviomc  support  facility 
conf igurat ions  with  respect  to  intended  as  well  as 
realized  support  capabilities  a  starvjard  approach  to  the 
integration  of  digital  avionics  support  facilities  is 
discussed  noting  that  responsive  mission  support  and 
reduced  life  cycle  costs  may  result  The  classic  component 
capabilities  of  tne  USAF's  Avionics  Integration  Suppor* 
facility  (AISF)  are  examined  for  dynamic  simulation 
Avionics  test  and  ir  egration.  offline  computation  and 
flight  test  Tne  advantages  and  disadvantages  of  the 
present  Aisf  approach  are  discussed  noting  the  expense  of 
the  single  System  approach  Attention  is  given  to  the 
first  building  block  in  the  standrrdned  AISF  approach 
called  the  Dynamic  Simulation  system  and  an  analysis  ot 
the  inree  core  elements,  including  the  simulation 
processor,  is  presented  79/00/00  79A48647 


UTTl  Potential  effects  of  stanoarOl rat  ion  on  avionics 
software  life-cycte  cost 

AUTH  A/SCmaNE  R  N  8/WULIAMS  J  R  .  C/YACMOWSKY  M  F 
PAA  B/<Looieon  Inc  .  Dayton,  ChIO),  C/(USAF, 
Aeronautical  Systems  Div  .  Wr ight -Pat terson  AFB,  Ohio) 

Ih  NACCON  1979  Proceedings  of  the  National  Aerospace  and 
Electronics  Conference  Dayton,  Ohio  May  15-17  1979 

Volume  2  (A79*48590  21-01)  New  York.  Institute  of 

Dectrica)  and  Electronics  Engineers,  Inc  1979,  p 
558 -5b7 

ABS  Quantitative  models  are  developen  to  evaluate  the 

potential  effect./  of  standardizat  ton  on  avionics  software 
life  cyclo  cost  Four  candidate  standard f rat  ton  areas  are 
invostiga'ed  computer- language  standardizat ion  standard 
cross-training  of  maintenance  personnel  standard  GFE 
support  hardware  and  software,  and  standard  interfaces 
Standardizat lon-cost-savings  models  are  defined  relative 
to  the  baseline  cost  of  a  hypothetical  non-stanflardized 
avionics  s/stem  Tiia  baseline  system  is  defined  to  include 
nine  subsystems  each  with  an  embedded  computer  and  an 
operational  flight  program  (OFP)  Life-cycle  costs  of  the 
baseline  system  are  computed  using  a  detailed 
rule  of-thumb  model  constructed  as  a  composite  of  current 
cost  data  and  models  from  the  literature  79/00/00 
79A48637 


UTTL  Av'onics  computer  software  operation  end  support 
cost  est imat ion 

AUTH  A/f£RENS  U  V  .  8/MAWRIS.  R  L  PAA  B/(USAF.  AvioniCS 
Laboratory  wrtgnt-Patterson  AFB,  Ohio)  In  NAECON  1979 
ProceediriQi  of  the  National  Aerospace  and  Electronics 
Conference,  Oa/ton  Ohio,  May  i5-17.  1979  volume  1 
(A79-48590  21-01)  New  York  Institute  of  Electrical  and 
Electronics  F-gineers.  »nc  .  1979,  p  296*300 

ABS  This  paper  doseribes  manv  ru-mot  wn/je’s  erd 

available  for  predicting  computer  software  operational  and 
support  costs  and  discusses  the  limitations  of  available 
models  and  methods  as  useful  tools  This  paper  also 
discusses  in  detail  tne  Air  Force  Avionics  Laboratory's 
current  effort  to  develop  0  model  that  win  help  tno 
engineer  or  cost  analyst  accurately  predict  operational 
and  support  costs  of  avionics  systems  computer  software 
being  maintained  ot  Air  Force  Air  Logistics  Centers 
79/00/00  79A43620 
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UTTL  RTCA  Standards  *  Irrproved  specs  and  regulations 
AUTH  A/fuCHS  w  C  PAA  A/<Radto  Technical  Con«iss»on  for 
Aeronautics  Washington,  0  C  )  In  Annual  Reliability 
ano  Maintainability  Synposiun,  Washington.  D  C  January 
23-25  1979  Proceedings  (A79*39816  16-38)  New  York 

In3titute  of  Electrical  and  Electronics  Engineers  1979. 
p  381*383 

6$  The  Radio  Technical  Commission  for  Aeronautics  (RTCA) 

develops  minirauffl  performance  standards  for  avionics  and 
telecommunications  These  standards  have  been  employed  as 
specifications  by  manufacturers  and  have  also  served  as 
the  basis  for  government  regulation  of  the  aviation 
industry  Subjects  under  consideration  by  RTCA  cortnittees 
during  1978  included  ground  proximity  warning  equipment, 
emergency  locator  transmitters,  airborne  Omega  receivers 
future  civil  aviatior  frequency  spectrum  requirements  and 
the  role  of  mean- 1 ime-bef ore-fat  lure  data  in  specifying 
safety  standards  79/00/00  79A399t9 


UTTL  Life  evdo  costing  of  simulated  vs  actual  equipment 
for  intermediate  maintenance  training 

AUTH  A/EGGEMEIER  F  T  B/RLEIN,  G  A  PAA  B/(USAF  Human 
Resources  Laboratory,  Wr ight -Patterson  AF6.  Ohio)  In 
Human  Factors  Society  Annual  Meeting,  32nd.  Detroit 
Mlch  .  October  16-19  1978  Proceedings  <A79- 18201  05-54) 

Santa  Monica.  Calif  Human  Factors  Society  Inc  1978. 
o  267-271 

ABS  initial  results  are  presented  of  a  two-phase  effort  to 
develop  life  cycle  cost  (LCC)  estimates  of  training 
equipment  for  F-16  avionics  intermediate  station 
maintenance  personnel  This  initial  phase  was  a 
preliminary  analysis  of  major  cost  factors  dif ferunt lat mg 
simulated  and  actual  test  equipment  It  was  conducted  to 
provide  an  early  estimate  of  the  cost  of  a  training 
simulator  and  to  decide  if  a  more  detailed  LCC  study  was 
warranted  Total  estimated  I5  yea-  costs  for  simulated 
equipment  trainers  were  approx imate ■ y  50%  less  than 
comparable  estimates  for  actual  equipment  trainers 
78/00/00  79AI02I7 


UTTL  CITS  •  Tomorrow's  test  system  today 

AUTH  A/OERBYSHIRE .  K  PAA  A/(RoCkwe11  International  Corp 
1.03  Angeles,  Calif  )  In  Industry/joint  Services 
Automatic  Test  Conference  and  workshop  on  Advanced  lest 
Technology  Management.  Acquisition  Support  San  Q.ego. 
Calif  April  3-7  1978,  ProceeOings  <A79- 16426  04  J8 ) 

Washington.  0  C  National  Security  Industrial 
Association,  1978,  p  Il2  tl4 

ABS  The  Central  Integrated  Test  System  (CMS)  developed  for 
the  6*1  aircraft,  allows  the  6*t  to  meet  the  requirements 
of  sel f -suf f iciency  uno  flight  hours  to  maintenance  of  an 
advanced  aircraft  CITS  cent tnuously  r.onitor$  all  aircraft 
subsystems  m  flight  and  on  the  ground,  and  performs  fault 
isolation  to  the  LRU  level  Maintenance  is  accomplished 
through  tn©  use  of  CITS-suppl led  failure  data  and  system 
operation  is  verified  through  the  use  of  CIT-t  active 
ground  tests  78/00/00  79AI643I 


UTTl  Advanced  technology  impact  upon  ATE  self  test 
AjTH  A/YOUNG  W  PAA  A/(Bendix  Corp  Test  Systems  Olv 
Teterboro  N  J  )  In  AUTOTESTCON  '77.  Symposium 
Hyannis,  Mass  ,  November  2-4  1977  Record  (A79-12301 

03*33)  New  York,  Institute  of  Electrical  and  Electronics 
Engineers.  Inc  .  1977  p  72-77 
A8S  The  paper  examines  the  opportunities  afforded  to  ate 

self-test  by  tne  use  of  microprocessors  and  LSI  Current 
self-test  concepts  are  briefly  examined  in  terms  of 
inherent  ambiguities  testability,  and  the  need  for 
accessory  tost  equipment  The  concept  of  using  intelligent 
instruments  along  with  compact  diagnostic  module  testers 
within  the  framework  of  a  large  ATE  system  »s  treated  as  a 
viable  cost-effective  approach  to  current  ATE  self-tost 
problems  77/00/00  79At2306 


UTTL  Support  systems  for  advanred  military  electronic* 

AUTK  A/KCNNCY,  J  W  PAA  A/(General  Oynam'es  Corp  Fort 
Worth.  Tex  )  In  AUTOTESTCON  '77  Symposium.  Hyannis 
Mass  Novemoer  2-4  1977.  Record  (A79-12301  02-33)  New 

York.  Institute  of  Electrical  and  Electronics  Engineers. 
Inc  .  1977  p  64-71 

ABS  The  paper  examines  some  of  the  ways  In  which  support 
systems  are  likely  to  change  to  keep  in  step  with  new 
avionics  approaches  It  is  found  that  those  factors  which 
will  probably  have  the  greatest  influence  on  AT£  support 
Systems  are  improved  reliability,  total  digital  designs, 
standardization  of  processors,  software  and  systems 
operation  monitoring,  and  on-s»Btion  SRu  (Shop  Replaceable 
Unit)  operations  Of  lesser  importance  are  concepts  such 
as  dynamic  reconf igurat lOn  and  redundancy  77/00/00 
79A 12305 


UTTl  An  analytical  method  of  defining  low  life  cycle  cost 
avionics 

AuTM  A/BLOXON.  W  0  .  B/KENNEDY.  C  0  PAA  A/(Boeing 
Wichita  Co  ,  Wichita  Kan  ),  B/(USAF  Aeronautical 
Systems  Olv  Wr ight-Pat terson  AFB.  Ohio)  In  NAECON 
'78,  Proceedings  of  the  National  Aerospace  and  Electronics 
Conferenr©  Oavton  Ohio  May  ia-ib  iot*  3 

<A76-49d5i  22-04)  New  York,  Institute  of  Electrical  and 
Electronics  Engineers.  Inc  ,  1978  p  <323-1224 

ABS  The  present  study  provides  a  basis  for  defining  a 

modernized  strategic  avionics  system  to  meet  the  in^roved 
performance  and  reduced  operation  and  maintenance  costs  to 
support  strategic  operational  requirements  In  the  1980s 
The  analysis  shows  that  a  dramatic  cost  effectiveness 
improvement  can  bo  achieved  over  the  baseline  and  that 
current  technology  will  support  the  guide  requirements  for 


life  cycle  cost  and  performance  In  order  to  meet  SAC's 
requirements  the  following  features  are  necessary 
improved  radar  resolution,  high  jamming  resistant  terrain 
following  radar  good  radar  performance  in  weather  radar 
mage  freeze.  Class  I  inertial  system,  low  altitude 
penetration,  and  redundancy  for  mission  success 
78/00/00  78A49990 


UTTL  Life  cycle  testing  for  avionics  development 
AUTH  A/HANCOCK.  R  N  PAA  A/(Vought  Corp  .  Dallas.  Tex  ) 

In  NAECON  '77  Proceedings  of  the  National  Aerospace  and 
Electronics  Conference,  Dayton.  Ohio.  May  17-19  1977 

(A7e-IS5Si  04-33)  New  York.  Institute  of  Electrical  and 
Electronics  Engineers.  Inc  .  1977,  p  46-53 
ABS  The  paper  reviews  recent  000  avionics  reliability 
improvement  activities  in  developing  the  roles  of 
laboratory  and  flight  testing,  with  emphasis  on  the 
importance  of  the  integrated  test  plan  and  Involvement  of 
all  affected  engineering  disciplines  The  status  of  000 
test  standards  revisions  is  discussed  and  a  general 
assessment  is  made  of  the  effect  of  these  revisions  on 
test  procedures,  facilities  and  costs  It  is  found 
necessary  to  use  various  degrees  of  life  ^vcle  event  and 
environmental  simulation  when  testing  at  the  various 
Systems  levels  from  piece  parts  to  total  system 
77/00/00  78A15557 


UTTL  future  aerospace  digital  signal  processing  concepts 

AUTH  A/HSUEH  S  F  .  B/VOJIR  W  .  C/BURKHAROT ,  P  PAA 
C/(Grumman  Aerospace  Corp  9ethpage  NY)  In 
Cof^uters  in  Aerospace  Com  Y-'ence.  Los  Angeles  Calif 
October  31-Novemoer  2  1977.  Collection  of  Technical 

Papers  (A78-126S1  02-59)  New  York,  American  institute  o' 
Aeronautics  and  Astronautics,  Inc  1977  o  75-fa1 

ABS  The  paper  attempts  to  outline  likely  requirements  for 

signal  pro'*essing  m  avionics  in  the  future  (up  to  1985 
and  beyond)  and  to  indicate  some  of  the  considerat ions 
that  will  influence  the  design  and  performance  of  future 
signal  processing  machines  Emphasis  is  placed  on 
currently  successful  techniques  which  should  be  exploited 
for  multipurpose  applications,  and  oh  the  fact  that  a 
fflultiput.ose  programmable  Signal  processor  is  needed  which 
meets  the  full  diversity  of  major  avionics  applications 
Functional  modulerity  and  software  commonality  are 
recommended  as  areas  of  standardization  which  will  allow 
for  growth  in  device  technology  and  theorefca’ 
developments 

RPT»  AIAA  77-1389  77/00/00  78AI3661 


UTTl  a  new  avionics  thermal  control  concept 

AUTM  A/TOKEN.  K  H  PAA  A/ ( McDonn© 1 1  Aircraft  Co  St 
LOUIS.  Ho  >  A$ME  SAE.  AlAA  ASMA.  and  AlChE. 
Intersociety  Conference  on  Environmental  Systems  7th.  San 
Francisco.  Calif  July  11-I4,  1977,  ASME  10  P 

A6S  The  use  of  more  efficient  thermal  control  techniques  for 
cooling  avionic  systems  on  fighter  aircraft  can  retKice 
avionic  failure  rates  and  aircraft  weight  penalties  due  to 
cooling  systems  Thus,  significant  economic  OenefltS  m 
initial  aircraft  purchase  cost  and  in  reduced  cost  of 
ownership  may  oe  possible  in  addition  to  increasing  the 
dependabi 1 1 ty  of  increasingly  important  avionic  systems 
This  paper  describes  a  heat  pipe-liquid  cooling  concept 
for  avionic  system  cooling  which  exhibits  higher  thermal 
efficiency  than  Currently  used  cooling  techniques  The  new 
heat  pipe  cooling  concept  allows  higher  temperature 
coolants  to  maintain  avionic  components  at  lower  operating 
temperature,  thereby  increasing  avionic  reliability  and 
reducing  aircraft  weight  penalties  incurred  by  the  rool mg 
System  Key  technical  developments  required  for  the 
implementation  of  the  new  cooling  technique  are 
Identified  Measured  thermal  performance  for  small  neat 
pipes  which  were  developed  for  the  new  cooling  system  are 
presented 

RPTY  ASME  PAPER  77-ENAl>- 14  77/07/00  77A46855 


UTTL  Avionic  power  supplies  -  Integrity  aspects 
AUTh  a/BRITNEll  C  PAA  A/(cwll  Aviation  Authority.  London 
England)  In  Symposium  on  Avionics  versus  Electrics  - 
Mho  Should  Determine  Future  Power  Supplies,  London 
England  March  15,  1977  Proceedings  {A77-38458  17-07) 
London.  Royal  Aeronautical  Society  1977  14  p 

ABS  Present-day  airworthiness  regulctions  are  considered 

sufficient  to  facilitate  the  cer t ■ r icat ion  of  the  g  eat 
majority  of  new  and  projected  avionic  systems  and  their 
electrical  power  supplies  However,  additional 
requirements  appear  to  be  noedeq  to  allow  the 
cer t If ica t Ion  of  those  new  types  of  hign  integrity  system 
which  are  requ.red  throughout  flight  and  where  a  common 
mode  fault  affecting  eltfier  the  system  hardware  or 
software  would  have  hazardous  consequences  The  solution 
•s  likely  to  be  a  procedural  one,  involving  the  careful 
development  and  rigorous  application  Of  new  requirements 
written  in  terms  Of  essential  design  features  and 
procedures  77/00/00  77A38463 


uiiL  <he  Electronically  Agile  Radar's  'balanced  design', 
and  Its  Importance  to  life  cycle  cost 
AUTH  A/MUKAI.  0  M  .  B/ATKINSON.  P  E  PAA  A/(USAr 
Avionics  Laboratory.  Ifright-Patterson  AFB,  Ohio). 

B/(WeSt inghouse  Defense  and  Electronic  Systems  Center 
Baltimore.  Md  )  In  NAECON  '76.  Proceedings  of  the 
National  Aerospace  and  Electronics  Conference.  Dayton, 
Ohio,  May  18-20.  1976  (A77-37352  l7'33)  New  York 

Institute  of  Electrical  and  Electronics  Engineers.  Inc  . 
1976.  p  379-386 


B-ll 


a6S  The  &  Iqc  t  roh  iCA  1 1  y  Agile  RAClar  (CAR)  is  being  designeci  to 

DO  corrpataDle  with  the  B-l  B  52  or  f6-1tt  weapons  AUTH 

systems  It  was  dedOed  to  use  an  CAR  design  philosophy 
which  balanced  overall  rcdv i rements  such  as  performance 
reliability  namtai  nab  1 1  1 1  y  nucleai 

swrv  1  vab 1 1  1  ty/vij I nerab  1 1  1  ty .  and  cost  in  such  a  way  as  to 
min«mi2e  the  overall  CAR  life  cycle  cost  The  oojectivo  of 
this  balanced  design  concept  is  the  elimination  of  the  ABS 

tendency  of  one  roquiremont  to  drive  the  radar  design  to 
an  unacceptable  cost  76/00/00  77A37402 


UTTL  Increasing  system  reliability  with  BITE 
AUTH  A/PLICE.  W  A  «>AA  A/(Mohevwel1  IhC  St  Louis  Park 
Minn  )  In  NAECON  '76  Proceedings  Of  the  National 
Aerospace  and  Electronics  Conference.  Dayton,  Ohio  May 
18-20  1976  (A77-3735?  17-33)  New  York  Institute  of 

Electrical  and  Electronics  Engineers  Inc  ,  1976  p 
208-214 

ASS  The  paper  reviews  the  basic  concepts  of  onboard  testing  of 
avionics  with  Bui  1 1 - In- Test  Equipment  (BITE)  and  considers 
the  effects  of  onboard  test  capability  on  system 
reliability  A  central  onboard  test  system  concept  is 
discussed  and  an  adaptive  modeling  concept  is  introduced 
which  offers  potential  for  increased  testing  capability  at 
reduced  cost  in  a  computer -based  avionics  system 
76/00/00  77A37380 

AUTH 

UTTL  SEM  •  Building  block  for  optimized  avionics  cost 
AUTH  A/STALEi,  w  w  PAA  A/ ( wes t inghouse  Defense  and 

Electronic  Systei.is  Center.  Baltimore.  Md  )  In  NAECON 
■76,  Proceedings  of  the  National  Aerospace  and  Electronics 
Conference  Otyton  Omo.  May  18-20  (976  (A77-37352 

17-33)  New  York  Institute  of  Electrical  and  Electronics 
Engineers  Inc  1*76  p  51-57  ABS 

ABS  The  objectives  of  the  program  to  develop  a  Stahdaro 
Electronic  Module  (SEM)  for  avionics  are  to  reduce 
acquisition  and  maintenance  costs  ana  to  improve 
reliability  and  availability  of  -eplacement  parts 
Attention  is  given  to  whether  star dardizat ion  is  practical 
in  aviOh’cs  anpl icat ions  and  what  should  the 
standardization  ne  It  is  concluded  that  there  are  no 
terhnicai  obstacles  for  a  succesfui  SCM  once  proper 
ir'entives  are  provtoed  76/00/00  77A37369 


UTTl  a  marketplace  approach  to  military  avionics 
standardization 

AUTH  A/SMITH,  C  N  D  PAA  A/fAriiic  Research  Corp 

Annapolis  Md  )  In  NAECON  '76  Proceedings  of  the 
National  Aerospace  and  Electronics  Conference  Dayton 
Ohio.  May  18-20  1976  (A77-37352  17-33)  New  Yor« 

Institute  of  Electrical  and  Electronics  Engineers  (nc  auTh 

1976  p  33-41 

ABS  This  paper  evplores  the  commercial  practices  widely  used 
toda  by  the  airlines  industry  to  develop  effective 
avionics  specifications  aro  high-quality  hardware 
Principal  among  these  practices  is  the  Airlines  ri^ctronic  ABS 
Engineering  Com.mtttee'S  open  forum  process,  the  use  of 
fo<m  fit,  and  function  spec i f icat ions  the  use  of 
marketplace  forces  tii«»  application  of  warranties  and 
data  exchange  within  tne  Avionics  Maintenance  Conference 
It  describes  some  of  the  ma)  .*  elements  of  these  practices 
and  e«o  ores  their  potential  impact  on  competition 
profit  reliability,  ma mta i nabi 1 i t/  and  life-cyCle 
costs  The  possible  appi *cat ion  of  commercial  avionics 
acquisition  processes  to  the  miutary  environment  is 
reviewed  76/00/00  77A37358 

AUTm 

UTTl  Tf’e  reliability  and  costs  of  RAf  tvionic  eqjipmeht 

AUTH  A/OOUTY.  P  A  PAA  A/fRAF  London.  England)  In 

Symposium  on  Equipment  ana  Systems  Design  for  Mmltsum  Cost 
Of  Ownership,  London,  England  March  16,  1976  ABS 

Proceedings  (477-22751  08-83)  London.  Royal  Aeionautical 
Society  1976  13  o  .  Discussion,  p  Ai-AiO 

ABS  Reliability  and  mainta i nabfl i ty  requirements  as  related  to 
the  ownership  costs  of  RAf  avionic  equipment  are 
discussed  Particular  attention  is  given  to  cost  savings 
from  improved  reliability  Of  aircraft  to  savings  from 
Improved  reliability  In  avionic  systems,  ano  to 
mainta Inabi 1 1 ty  actions  to  reduce  cout  It  is  suggested  to 
reduce  the  increasing  dominance  of  maintenance  costs, 
which  would  result  in  freeing  funds  for  the  continued 
purchase  of  new  equipment  76/00/00  77A22752 


UTTl  ENP  hardening  of  aircraft  by  closing  the 
points-of -entry 

AUTH  A/MORGAN,  0  E  PAA  A/(8oc'weU  Internet lonal  Corp  .  AUTH 

Anaheim.  Calif  }  In  Inter  atlonal  Symposium  on 
E lectromagnet 1C  Compatibility,  San  Antonio,  Tex  October 
7-9.  1975,  Record  (A77-1540t  04-33)  New  York.  Institute 
of  Electrical  and  Electronics  Engineers  Inc  1975.  p 
3AIld1*3AIId6 

ABS  EM'’  (electromagnetic  pulse)  couples  radio  frequency  energy  ABS 

Into  aircraft  cables  by  a  senes  of  Interactions  with  the 
total  system  In  a  series  of  trade  studies  it  was 
concluded  that  to  harden  the  C-130  aircraft  against  EMP. 

It  would  06  most  cost  effective  to  begin  by  closing  tho 
points  of  entry  into  the  fuselage  It  was  indicated  that 
wCwiu  piuviuw  me  greatest  benefit  in  improving 
hardness  with  the  least  effect  on  cost,  weight, 
reliability,  and  maintainability  A  detailed  investigation 
was  begun  to  identify  all  the  points  of  entry  on  the 
C-130.  and  to  devise  ways  to  close  them  This  paper 
presents  preliminary  results  of  this  invest igat ion 
7«/00/00  77A15408 


UTTL  A  critique  on  third  generation  ATE  experience 
A/WILLIAMSCN,  P  H  PAA  A/(C9neral  Dynamics  Corp 
Electronics  Otv  ,  San  Diego  Calif  )  In  Automatic 
Support  Systems  Symposium  for  Advanced  Maintainability 

westbury.  N  V  October  28-30,  1975  Conference  Record  I 

(A76'4560l  23'C2)  New  York,  Institute  of  Electrical  and 
Electronics  Engineers.  Inc  1975  p  223-226 

A  third  generation  ATE  the  Hybrid  Automatic  Test  System  « 

(HATS)  IS  based  on  the  use  of  universal 

St imulus/neasurement  techniques  and  minicomputer  software 
to  reduce  the  amount  of  station  hardware,  the  use  of  a 
programmable  interface  to  reduce  the  number  and  complexity 
of  adapters  required,  and  the  use  of  an  Engl ish-i ike 
programming  language  which  permits  on-line  program 
generation  and  debug  The  experience  with  nine  hats 
Currently  used  for  Test  Program  Set  (TPS)  development 
shows  that  the  on-station  time  required  to  debug  a  program 
has  been  appreciably  reduced  by  on-line  proorarrming  and 
that  interactive  programming  has  reduced  the  dcveiopfent 
costs  of  TPS  The  problem  of  an  excessive  relay  failure 
rate  during  HATS  development  was  solved  by  developing  a 
dynamic  screening  test  for  relays  and  providing  self-test 
software  to  isolate  the  failed  relay  75/00/00 
76A4S631 


UTTL  Techniques  for  achieving  low  cost  strapdown 
nav I  gat  ion 

A/GlLMORE,  d  P  B/MCKERN  R  A  C/MUSOFF  H  PAA 
C/(Char)es  Stark  Draper  Laboratory  Jnc  .  Cambridge 
Mass  )  in  INTERCON  75  Interna t i ona 1  Convention  and 
Exposition,  Now  York,  N  Y  .  April  8-10,  1975.  Confe  ence 
Record  (A76-11826  02-33)  New  York  Inst  tute  of 
Electrical  and  Electronics  Engineers,  Inc  .  1975  p  i 
35/3-4  35/3 

Accurate,  rel table  and  less  vulnerable  radio  navigation 
systems  (GPS.  OMEGA  OME  and  LOPAN)  have  been  forecast  for 
the  early  I980s  This  radio  navigation  capability  permits 
a  reformation  of  the  INS  imple.ncntat  lon  lequirements  from 
those  of  stand-alone  navigation  to  that  of  high-bandwidth 
aiding  of  the  radio  navigator  Use  of  low  cost  stiapdown 
technology  m  this  application  area  oecomes  very 
attractive  Modularity  concepts  in  both  hardware  and 
software  are  presented  as  a  basis  for  achieving  such  a  low 
cost  goal  This  paper  presents  a  detailed  system  concept 
Showing  how  to  implement  a  strapdown  system  »n  the 
hign-bandwiOth  aiding  problem  and  how  to  integrate  ail  of 
the  conventional  inert iel -avlcntcs  subsystems  into  a 
unified  strapdown  system  75/00/00  76A11842 


UTTL  Ma  intam.  01 1  1  tv  payoffs  during  weapon-system  test  - 
The  value  of  appropriate  testing 

A/NELSON.  J  R  RAA  A/(BanO  Corp  Washington,  0  C  ) 

In  Annual  Reliability  anc  Maintainability  Symposium 
Washington  0  C  January  28-30  1975  Proceedings 

(A75-44202  22-38)  New  York  Institute  Of  Electrical  and 
Electron  C5  Engineers.  Inc  1976.  p  26-29 
A  summary  of  lessens  learned  from  a  decade  of  experience 
in  examining  developmental  and  operational  field  tests  of 
aircraft  weapon  Systems  is  presented  An  approach  to 
reconcile  oes ign- to-cost  ana  iife-cyde  cost  in  the 
context  of  ma i nta mab 1 1  1  ty  payoffs  during  .veapon-s/stom 
test  IS  discussfd  75/00/00  75A44204 


UTTl  Lessons  le.'Mnoa  through  a  mil-sto-  1563  time  division 
mol t iplox  bus 

A/BDOSE  £  F  PAA  A/(Mitre  Corp  Bedford,  Mass  ) 
m  NAECON  '75,  Proceedings  of  the  National  Aerospace  and 
Electronics  Conference.  Dayton,  Ohio  June  10-12.  ’975 
(A75-37623  18-01)  New  York  Institute  Of  Electrical  -md 
Electronics  Engineers.  Inc  .  1975  p  634-641 
An  experimental  time  division  multiplex  bus  designed  and 
built  in  accordance  with  the  MIl-STD  1553  standard  is 
described  It  consists  of  a  controller  bus  controller 
interface  unit  transmission  medium,  and  two  remote 
terminals  A  new  design  feature  is  the  use  of  a 
microprocessor  for  timing  and  control  functions  in  one  of 
the  remote  terminals  The  discussion  covers  the  spectrum 
of  the  signals  found  on  the  bus.  transmission  medium 
character  1st  ics .  the  partitioning  of  a  remote  ter.iilnal 
the  microprocessor  in  the  subsystem  interface  umt  signal 
conditioning  at  the  subsystem  interface,  and  candidate 
areas  for  furtr  r  investigation  75/00/00  75A37705 


UTTL  Reliability  and  the  cost  of  ownership 
A/PROCKTOR.  I  H  PAA  A/(8r1tlsh  Airways.  Ltd  ,  Luton 
Airport,  Beds  .  England)  Iri  Syfnposlum  on  the 
Application  of  Electrical  Control  to  Aircraft  Propulsion 
Systems,  London,  England,  February  20.  2l  1974, 

Proceedings  (A74-43201  22-28)  London  Royal  Aeronautical 
Society,  1974  8  p 

The  present  work  discusses  in  general  terms  some  of  the 

problems  arising  in  the  maintenance  of  aircraft  and 

suggests  guidalines  for  the  disciplines  of  reliability  and  - 

maintenance  control  After  certification  of  aircraft 

IS  vital  that  feedback  of  operators  experience  and  modes 

of  falUjre  should  rnniimu*  3<Je5"-a?C 

system  of  recording  analyzing,  and  reducing  information 

to  data  Route  faults  location  must  oe  expeditious,  and 

diagnosis  within  the  capability  of  tno  average  ' 

maintenance  man  Because  of  tne  many  interfaces  of  ^ 

components  and  systems,  system  interrogat ion  is  required  < 

rather  than  checks  on  individual  boxes  74/00/00  « 

74A43208  « 
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UTTL  The  role  of  electronic  Oispla/s  m  future  avionic 
systems 

AUTH  A/MCKINLAV  W  H  B/BRAIO  0  M  C/MATTHEWS.  M  A  V 
PAA  C/tFerranti  i tO  .  Hollinvooa  Lancs  ,  EngTano)  In 
The  future  of  electronic  aiSQlays.  Proceedings  of  the 
Ooint  Symposium.  London,  England  February  23.  1972 
(A72>32631  1S-02)  London,  Royal  Aeronautical  Society 
1972  13  p 

ABS  Oisciission  of  the  state  of  art.  and  of  present  ana  future 
trends  in  electronic  displays,  and  assessment  of  their 
expansion  potential  in  avionics  systems  An  effort  is  made 
to  achieve  a  perspective  in  which  electronic  display 
technology  is  related  to  other  technologies  which  have  a 
bearing  on  its  adcotlon  in  real  systems  Soocial  attention 
IS  given  to  computer  driven  displays,  or  displays  used  in 
systems  based  on  digital  data  exchange  72/00/00 
72A3263S 


UTTL  Acquisition  and  recording  an  AMX  A/C  Aentalia 
experience  and  present  trends 

AUTM  A/CAT7UNAR  5  CORP  Aeritalla  S  P  A  Turin  (Italy) 

CSS  (flight  Test  Development  )  Presented  at  the 
Eu'^opean  Telemetry  Conference  Aiv-en  Provence.  France 
iaa7 

ABS  Experimentation  with  the  BUS  1553  6  as  the  act*vo  link  for 
all  avionic  navigation  and  armament  equipment  m  an  amx 
prototype  AOS  aircraft  is  described  The  systei  allows  for 
acQutsition  rf  256  parameters  from  trensaucer  and  analog 
sources  Two  different  acquisition  techniques  through  a 
PCM  (pulse  code  modulation)  acquisition  system  and 
directly  on  a  maf  s*ic  tape  recorder  are  used  The 
results  of  the  expor imentat t on  helped  in  developing  a  unit 
allowing  for  considerable  savings  in  track  usage 

PPT*  ETN-89*95217  87/C>0/00  90Ni2598 


UTTL  The  B-iB  central  integrated  test  system  expert 
parameter  system 

AUTH  A/MONTGOMERY.  GERARD  J  CORP  Air  Force  .fright 

Aeronautical  tabs  .  Wnght-Patterson  AFa  Om  In 
Colorado  Univ  .  Proceedings  of  the  Air  Force  Workshop  on 
Artificial  Intelligence  Applications  for  Integrated 
Diagnostics  p  388-393  (SEE  N89-14740  0«-63) 

ABS  The  6* lb  Central  Integrated  Test  System  (CITS)  provides  u 
comprehensive  on  aircraft  diagnostic  capability  and 
records  approximately  19.600  parameters  The  B*t6  CITS 
Expert  Parameter  System  (CEPS)  is  an  initiative  »o  improve 
6l6  diagnostic  capaoilities  by  applying  expert  system  ana 
data  analysis  techniques  to  the  lo-f light  recorded  data 
The  manner  m  which  CEPS  enhances  8-i8  on  and  off  aircraft 
diagnostic  capabilities  and  reduces  false  alarm,  can  not 
duplicate  and  re-test  okay  accurrences  will  be  presented 
The  CEPS  capabilities  will  oe  discussed  and  an  overview  of 
the  accomplishments  and  status  of  tne  CEPS  program  win  pe 
given  Tms  paper  will  illustrate  the  appi  tcabi  I  i  tv  of  trie 
8-16  CEPS  concepts  to  otner  existing  and  future  weapon 
systems  The  ability  to  reduce  future  weapon  system 
built-in  test  requirements  tnrouqri  the  use  of  on-a  rcraft 
rxpert  systems  will  be  discussed  along  with  trie  need  for 
a  ground  based  diagnostic  system  87/07/00  89NU763 


UTTL  Design  for  mteroperabi I i ty  (interchangeability) 

AUTH  A/KCNOMOS,  GEORCE  CORP  Air  Force  Urignt  Aeronautical 
Labs  Wngnt-Patterson  af8  om  Jn  aCARO.  The  Design. 
Development  and  Testing  of  Complex  Avionics  Systems  5  p 
(SEE  N88-23767  17-06) 

ABS  Interoperability  of  the  various  elements  used  in  a  system 
IS  the  design  property  which  allows  the  intermixing  of 
elements  from  various  sources  (manufactures)  without  any 
impact  on  the  performance  of  the  system  or  the  operational 
hardware  Here,  the  line  replaceable  module  approach  is 
discussed  This  is  a  new  approach  to  avionics  where  a 
processor  modulo  is  a  6  inch  by  6  inch  plug- In  board  with 
processing  power  many  times  higher  than  that  of  older  lino 
replaceable  uh'ts  87/12/00  88(423‘'89 


UTTL  Oovelopmont  and  testing  of  a  predictive  methodo’ogy 
for  optimizttion  of  mon-nachmo  interface  in  future 
avionics  systems 

AUTH  A/PARKS,  ROGER  E  CORP  Textron  Coll  Helicopter  Fort 

worth.  TX  CSS  (Advanced  Human  Factors  System  Design  ) 
In  AGARO,  The  Design,  Development  and  Testir,g  of  Complex 
Avionics  Systems  9  p  (SFE  N8&-2376  17-06) 

ABS  The  ♦rend  toward  increasing  complexity  and  cost  in 

emerging  avionics  systems  driven  by  requirements  for 
increased  functional  capability  has  created  a  need  for  a 
predictive  analyttca'  methodology  which  accurately 
forecasts  system  performance  early  in  the  design  process, 
and  treats  the  human  operator  and  thi  equipment  as  a  fully 
integrated  man-nachine  system  A  methodology  that  meets 
these  needs  has  been  developed  and  validated  by  Bell 
Helicopter  Textron  The  process  is  being  use-  to  p-ovide 
early,  accurate  avionics  system  characterization,  thereby, 
reducing  design  costs  87/12/00  eSN23780 


UTTL  A  structured  approach  to  weapon  system  design 

AUTH  A/MALLEY  H  M  B/OEWELL  N  T  .  C/SMITM  RAC 

CCRP  British  Aerosbacj  Aircraft  Groix)  Preston  (Fnoland) 
CSS  (Military  Aircraft  Oiv  )  In  AGARO.  The  Oeslgn 
Development  and  Testi-vg  of  Complex  Avionics  Systems  12  p 
(SEE  N98-23767  17-06) 

ABS  A  structured  approach  to  tne  design  of  highly  Integrated 
weapon  systems  of  the  future  is  described  The  approach 
was  used  in  the  design  of  the  avionics  system  for  the  UK 
Experimental  Aircraft  Program  (EAP)  demonstrator  aircraft 
Brief  descriptions  are  given  of  the  EAP  systems,  the  mam 
systems  design  tools  used,  the  activities  carried  out 
during  the  systems  design  process  and  the  management  and 
control  procedures  adopted  A  series  cf  observations 


highlighting  some  of  the  findings  of  tiie  project  and 
providing  pointers  tn  the  design  of  future  weapon  systems 
IS  given  87/12/00  a8N23773 

UTTL  Avionics  acquisition  trends  and  future  approaches 
AUTM  A/lONGBRAKE  RONALD  B  CORP  Aeronautical  Systems  Div 

WnghfPatterson  AF8.  OM  CSS  (Directorate  of  Avionics 
Engineering  )  In  AGARD  Flight  vehicle  Development  Tima 
and  Cost  Reduction  11  p  (SEE  N88-20173  12-81) 
iBS  The  current  and  future  difoction  of  the  u  S  Air  Force 

avionics  is  discussed  while  tne  paper  discusses  primarily, 
tactical  aircraft  avionics  the  find.ngs  and  conclusions 
are  applicable  across  USAF  systems  The  paper  covers  the 
acquisition  methodology  the  background  and  trends  of 
avionics  and  future  approaches  The  bssic  influencos  are 
operational  needs,  availability  survivability,  available 
techivjlog/  cost  and  schedules  The  chall*»nge  is  to 
provide  effective  avionics  »n  a  budget  constrained  world 
To  acconw>'i-h  this  requires  emphasis  on  providing 
performance  to  counter  the  threat,  flexibility  for  diverse 
use  and  bas'ng.  cost  and  schedule  realism,  and  systems 
capable  of  being  upo' adea  trirougri  planned  growth  as  the 
threat  changes  It  has  been  shown  that  the  5  to  10  percent 
mprovemenrs  in  performance  can  increase  the  cost  20  to  50 
percent  therefore,  sufficient  and  not  best  performance 
should  be  the  goal  While  initial  acquisition  cost  is  of 
concern,  life  cycle  cost  is  even  more  important  To  keep 
life  cycle  costs  down  and  nave  un  effective  system  during 
combat,  maintenance  concepts  need  serious  attentici  To 
accomplish  these  objectives  tn©  discrete  avionics  systems 
of  the  past  rrust  be  replaced  with  integrated  avionic^ 
responsive  to  crew  needs  increasinn  threats  and  fiscal 
constraints  Future  needs  will  cause  continued  increases 
.n  avionics  cost  The  use  of  new  technologies  new 
avionics  system  integration  and  architecture  techniques 
use  of  common  hardware  modular  and  reusable  software  and 
improving  the  environment  in  which  the  avionics  rnust 
operate  can  control  the  life  cycle  cost  of  avionics  while 
meeting  needs  of  future  systems  87/09/00  88N20184 


UTTL  An  evaluation  of  perceptions  of  form  fit  function 
(F3)  standardization  on  tne  Standard  Inertial  Navigation 
unit  (STO  INU)  program 

lUTH  A/ROSENSTEEL.  THOMAS  F  CORP  Air  Force  Inst  Of  Tech 
wr ight ■Patters''n  AFB.  OH  '*$5  (School  of  Systems  and 
Logistics  ) 

ABS  This  Study  comp. red  percept  lyis  on  F3  standard i za t lon  by 

the  Avionics  Sta.'Oardization  Acquisition  community  and  the 
User  Avionics  candardizat  ion  Acquisition  corwnum'y 
focusing  on  the  STO  INU  Program  and  the  subset  of  the  two 
acquisition  conmumties  which  worked  with  the  STD  INU 
Program  A  survey  addressed  percoptiont  on  tfie  effect  of 
F3  standai di rat  ion  on  acquisition  costs  logist’cs  support 
costs  mission  availability  tnn  inertial  industrial  base 
new  technology  insertion  reliability  and  achieving 
program  Management  Directive  objectives,  the  costs  and 
oene'its  of  f3  standard i zat ion  ana  wnoth&r  or  not  the 
benefits  outweighed  the  costs,  etc  Tiie  most  often 
mentioned  benefits  were  redured  logistics  support  costs 
increased  force  readiness  and  reduced  acquisition  costs 
The  most  often  mentioned  costs  were  constant  configuration 
Changes,  increased  integration  costs  and  humorous 
aircraft  interface  leouirements  About  half  the  Survey 
participants  recommended  standardizing  at  a  lower  le/el 
1  e  .  modular  standai di zat ion  for  both  the  ring  laser 
gyro  at'd  the  next  generation  STD  INU  Prog'^ams 

RPIw  A0-A18B9S5  AF I T/Q3M/LSY/870- 1  87/12/<X)  88N19446 


UTTi  Supportab  1 1  I  ty  ih  aucraft  systems  through 
technology  and  acquisition  strategy  applications 

AUTH  A/MALEY.  DEBRA  L  CORP  Air  Force  Inst  of  Tech 

Wr ight -Patterson  AFB,  OH  CSS  (School  of  Systems  and 
Logistics  ) 

ABS  The  importance  of  high  reliability  systems  tn  tne  national 
defense  strategy  of  force  multiplier  is  paramount 
Currently,  the  Air  Force  has  adopted  R^'l  lability  and 
Maintainability  <R6M)  2(X>0  as  a  manageme'it  policy  to 
achieve  high  rol labi l ‘ t tes  However  there  are  few  methods 
being  implemented  which  can  improve  the  measures  of 
rel iabi I i ty  One  method  used  wi th  success  by  sa»ol I i t© 
systems  IS  tf>e  use  of  expensive  but  highly  reliable  class 
S  electronic  parts  as  opposed  to  the  class  B  parts  used  m 
avionics  ana  ground  electronic  systems  A  method  for 
determining  the  improvement  of  systems'  Mean  Time  Between 
Failure  (MTBF)  was  developed  Additionally  the  Impact  of 
improved  system  MT8F  along  with  higher  acquisition  costs 
as  a  result  of  using  class  S  parts  was  analyzed  in  a  life 
cycle  cost  model  Results  obtained  m  this  research 
indicate  that  class  S  parts  nave  the  potential  of 
significantly  increase  MTBF  while  actually  lowering  life 
cycle  costs  Rerommendat ions  for  fol low-on  research  are 
given 

RPTw  A0-A186465  AFIT/GIM/L5M/87S-30  87/09/00  88N15759 


UTTL  Design  principles  and  practices  for  tmplemertat ion 
of  MIL  ;>TD-1760  in  aircraft  and  stores 
AUTM  A/LAUTNEft.  D  E  .  B/MA8EK.  A  U  .  C/DRUM  W  M 

O/FERNANOEZ  R  R  CORP  LTV  Missiles  and  Electronics 
Crnuo  Dallas  C9'>  (Missiles  Div  ) 

ABS  The  trends  in  weapon  system  designs  (aircraft  and  stores) 
has  resulted  m  a  growing  concern  over  the  general 
proliferation  of  aircraf t - to-stor e  electrical  interfacing 
requiremehis  and  the  resulting  high  cost  to  achieve 
interoperab 1 1 1 ty  between  aircraft  arxJ  stores  MIL-STO-1760 
was  pr-’pared  to  reduce  tne  aircraf t/store  electrical 
integration  oroblem  by  specifying  a  standard  electrical 
interface  between  aircraft  and  stores  The  standard 
electrical  interface  is  based  on  lO  ognizod  trends  in 
store  managemerit  systems  which  use  ia1  digital 
transmission  for  control,  monitor,  and  release  of  stores 
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This  repol  t  deals  with  the  iri»eroperabi  1 » t/  reQ^ircnents 
as  descf'ibed  ui  MIL-STD- neo  dh<l  is  intended  to  oe  an  aid 
to  under s tending  and  meeting  the  requ irements  for  both 
current  and  future  weapon  systems  In  genera)  this  report 
provides  the  following  (t)  An  overview  of  Mil  S7P  1760 
requirements  exclusions  and  future  growth  provisions  (2) 
Detail  design  considerations  applicable  to  the  Aircraft 
St<rtion  Interface  (ASIl  (3)  Detail  design  considerations 
appi icaple  to  the  Mission  Store  Interface  (MSI)  (4) 

A  I rcraf t/S tor©  Physical  Oes  gn  Consideration'  (S)  A 
commentary  on  the  requirements  in  MIL-STO  1760 
DPT#  A3-A18372‘.  REPT-3-52110  6R-128  87/06/00  88^10027 


U^TL  Aircraft  e ■ cc tromagr at ir  compatibility 
AUTH  A/CIARKE  ClIFTON  A  B/IARSCN.  WllllAM  C  PAA 

e/(Fooer8l  Aviation  Adm mistrat ion  Moffett  Field  Calif  ) 
CORP  Boeing  Commercial  Airplane  Co  .  Seattle.  WA 
ABS  Illustrated  are  aircraft  architecture  electromagnetic 

interference  environments  electromagnetic  compatibility 
protection  techniques  program  specifications,  tasks  and 
ver t f icat ion  and  validation  orocedures  The  environment  of 
400  H2  power,  electrical  ♦ransients  and  radio  frequercy 
fields  ar©  portrayed  and  related  to  thresholds  of  aviomrs 
dlectrohics  F we  layers  of  protection  for  avionics  ar© 
defined  Recognition  is  given  to  some  present  day 
electromagnetic  compatibility  weaknesses  and  issues  which 
serve  to  reemphasize  the  importance  of  EMC  verification  of 
equipment  afid  parts,  and  their  ultimate  EMC  validation  on 
the  aircraft  Proveh  standards  of  grounding,  bondi.ng 
shielding  wiring  and  packaging  are  laid  out  to  help 
provide  a  foundation  for  a  comprehensive  approach  to 
successful  future  aircraft  design  and  an  understanding  of 
cost  effective  EMC  m  an  aircraft  setting 
RPT#  NASA-CR- 181051  WAS  1  26  IfilOSl  COT/FAA/CI  86/40  D6-53840 
87/06/00  87N23856 


IJTTL  Some  development  trends  in  light  ground  attack 
a  1 rcraf  t 

AUTH  A/TCNINl  ft  B/AVAONIfJA .  G  M  C/lOOACONO  E 

0/6ftAGAGN0l0  M  PAA  0/(Aerita1ia  $  p  A  Caselle 
Tonnese  Italy  )  CORP  Italian  Air  Staff  Rome  In 
AGARO  Improvement  of  Combnt  Performance  for  Existing  aro 
Future  Aircraft  16  p  (SEE  N87-22663  16-05) 

•IBS  Tfc©  deve'opment  of  a  light  oemper  attack  aircraft  am-^ 
IS  discussed  Specific  design  requirements  and  cost 
effectiveness,  a  mission  effectiveness  moiJei 
effectiveness  tradeoffs  weapon  systems  and  avionics  ’ire 
among  a  topics  surveyed  86/12/00  87N22666 


UTTi  Avionics  standard  I  rat  ton  Perceptions  and 
recommendat ions 

AUTH  A/FURRU  d  A  CQRP  Air  Force  Inst  Of  Tech 

Wright  Patterson  AF8  Oh  CSS  (School  of  Systems  and 
Logist ICS  ) 

ABS  ihis  research  effort  reflects  th©  perceptions  and 

attitudes  about  avionics  standardization  py  some  members 
of  the  acquisition  community  Alt  of  the  interviewees  were 
knowledgeab I©  on  the  subject  of  and  many  nad  extensive 
experience  with  avionics  standardi  zat  ion  Ttiey  either 
were  currently  working  or  had  previously  worked  with 
avionics  stanoardizat ior>  The  analysis  reflects  som©  of 
the  attitudes  about  the  policies  and  procedures  of 
avionics  stanoardizat .on  and  the  role  of  ti©  Deputy  for 
Avionics  Control  in  the  process  of  standardization  the 
analysis  also  includes  recommended  changes  to  the  current 
process  of  stanoardi z mg  avionics  equipment  the  result  of 
the  research  ©f'ort  shows  that  th©  acquisition  community 
has  not  arreptod  avionics  stanoar dizat ion  for  a  number  of 
reasons 

RPT#  A0-A1Ct709  AF IT /GSM/ L6r/85S  It  85/09/00  86N20J88 


UTTi  fvavy  Should  join  the  Air  Force  and  Army  pregram  to 
develop  an  advanced  ir'tegrateq  aviooi«-s  system  CORP 
General  Accounting  Office  Washingtc  i.  DC  CSS  ( 
\atKmf1  Security  and  (ntornat  lono'  Affairs  Oiv  ) 

ABS  Modem  lechnoiogy  should  scon  enable  separate  avionics 
systeiips  in  an  aircraft  to  be  ronsolidated  into  a  sii*gie 
package  to  conserve  soace.  save  weight,  and  reduce  costs 
The  report  points  out  the  potential  benefits  of  avionics 
consolidation  and  recommends  the  Navy  join  In  a 
demonstrat  icn  program  now  being  conducted  by,  the  Air  Force 
and  Army  to  ©xploit  such  benefits 
HPT#  P885-222503  GA0/N5IAD-85-94  6-215379  85/06'i7  86N12224 


UTTi  Avionics  and  civil  aircraft  systems  Th©  present 
and  the  future 

At/TH  A/LABORIE  J  P  CORP  Societe  Natior.©!©  Indur trl«l  I© 
Aqrosoatiale  Toulouse  (France)  CSS  (Div  Avion  ) 
Presented  at  GIFAS  Semaine  Aeros'jastlai©  Francaise  de 
Conf  Tech  Madrid  12-15  dun  1984 
ASS  The  technological  progress  m  the  design  of  avionics 
systens  from  the  Concorde  to  the  Alrpos  family  is 
described  The  weight  reduction  cost  advantages  and  ease 
of  maintenance  obtained  with  numerical  techniques  and 
laser  gyros  are  discussed  The  ergonomic  advantages 
introduced  with  the  extensive  use  of  cathode  ray  displays 
are  po  ntod  ou*  The  design  trends  for  the  A310  and  longer 
terrx  evolution  ar©  ©x^'^1nod 
OPT*  S*‘i’*i.  25'  **'  ‘04  SO/ 02/18  ooNo  ivuo 


UTT'k.  Avtoh'us  data  base 

AUTH  A/MCGOWAN.  0  .  B/WON.  C  J  .  C/VAMETTEN,  0  CORP 
Applied  Systems  Irist  Inc  Washington  DC 
ABS  This  documcn;  is  a  compendium  of  data  for  u  S  commercial 
Kviomcs  equipmen*  produced  by  6l  manufacturers  It 
contains  data  for  the  Air  Transport  Associatton  lATA) 


Specification  lOO  categories  of  auto  flight 
communications  indicating  and  recording  and  navigation 
as  welt  as  for  antennas  ana  couplers  For  each  piece  of 
equipment  the  following  information  has  been  collected 
technical  specification  price  technical  standard  order 
number,  AtA  Specification  lOO  code  and  manufacturer  name 
address,  and  phone  numpoi  In  addition  to  this  ©port  the 
data  IS  available  in  machine  readable  form  compatible  with 
the  IBM  personal  con^uter  with  R  base  4000  Data  Base 
Management  System 

RPT*  A0-A1S2415  fAA-APO-85-4  85/01/00  S5N27863 


UTTi  Some  aspects  of  how  to  design  cost-effective  flight 
control  systems 

AUTH  A/OUT  TER  U  B/BOTZLER  L  CORP 

Messerschml tt-Boelko~  Blohm  GmbH.  Munich  (Germany 
f  R  )  CSS  (Aircraft  Div  )  In  AGARD  Cost  Effective 
and  Affordable  Guidance  and  Control  Systems  14  p  (SEE 
N85'2663B  16-01 ) 

ABS  The  design  of  flight  control  systems  for  fighter  aircraft 
•s  discussed  with  respect  to  areas  which  contribute  to 
minmizirj  life-cycle  costs  As  I'fe  cycle  costs  include 
all  costs  accumulating  during  the  whole  life  of  the 
System  all  phases  from  the  design  to  in-service  use  are 
considered  Any  structural  and  technological  design 
features  that  are  introduced  to  save  costs  during  system 
operation  and  maintenance  require  additional  development 
effort  Therefore  the  expected  co^t  benefit  has  to  be 
balanced  against  the  devniopraent  nffort  invested  into  the 
system  to  achieve  a  cos* -ef f ec 1 1  ve  design  85/02/00 
8SN26C39 


uTTi  Reliability  predictions  for  military  avionics 
Royal  Signals  and  Radar  Es tab! i shment  reliability 
prediction  method  no  250  CORP  Royal  Signals  and  Radar 
Establishment  Malvern  (England!  C5S  (Reliability  and 
Environmental  Engineering  Section  ) 

ABS  A  prediction  model  for  military  avionics  applications  18 
isonths  after  an  qquipment  is  first  introduced,  is 
presented  Jase  component  failure  rates  with  max’mur^ 
Stress  levels  aro  presented  Factors  influercmg  avionics 
reliability  are  outlined 
RPT*  eR6922!  77/09/00  85N22388 


UTTi  Standard  Attitude  Heading  Reference  System  (SAhhs) 
full  Stale  development  program 

aijTm  A/BACMMAN,  k  I  CORP  Naval  Air  Oevelopwent  Center 
Warminster  PA  In  AGARO  Helicopter  Gndance  and 
Control  Systems  for  Battlefield  Support  12  p  (SEE 
N85-  16797  08-01 ) 

ABS  There  is  a  recognized  need  within  the  military  services 
for  reliable  'ow  cost -o* -ownership  attitude  Heading 
ftoforenc©  Systems  (AHftS)  capable  of  operating  for  extended 
periods  without  the  need  for  ca 1 ibrat lOn  or  regularly 
scheduled  mainterance  In  recognition  of  this  heed  the 
military  services  have  ernbarKPd  up  in  a  joint  snvico  full 
scale  ongineenrg  deveiopme’'*  program  to  provide  a 
Standard  Attitude  Heading  Reference  Svstem  (SAhrS) 
utiiiz<ng  strapdown  technology  for  a  multiplicity  of 
lotary  and  fixed  wing  platforms  System  desigri  concepts 
and  performance  char acter  i  s t  ics  are  dcscr  jbed  Piocuremont 
and  schedules  are  also  discussed  84/'09/00  85Ni6eo4 


U’Tl  Design  for  Tactical  Avionics  Maintainability  CURP 
Advisory  Croup  for  Aerospace  Research  and  Development 
Neui 1 ly-Sur-Seine  (France)  Conf  held  in  Brussels.  /  10 
May  1984  ANN  Advanced  methods  ana  tools  to  support 
design  for  aviomc  maintainability  and  testability,  are 
discussed  Both  hardware  and  software  design  for 
mointamabi  1  1  ty  issues  and  approaches  are  addressed  For 
individual  titles  see  N85-56732  through  N85-lb756 
RPT*  auA»D'CP-361  ISBN-92-835-0366-10  AD-A‘49199  84/10/00 

85N16731 


UTTl  Increased  Joint  avionics  standardization  could 
result  1  -ajor  economies  and  operational  benefits  CORP 
Gcneial  iccovinting  Office  Washington,  DC  CbS  ( 
National  Security  and  International  Affairs  Oiv  ) 

AB..  This  report  discusses  the  Oepar-ment  of  Defense's  efforts 
to  standardize  tact  cal  avionics  subsystems  and  tnn  need 
to  provide  better  support  for  those  activities  The 
objective  was  to  look  at  the  progress  made  in 
standar d I z mg  core  avionics  subsystems  by  the  Joint 
Services  Review  Comnlt*ee  for  Avionics  Cor*pc>nonts  and 
Subsystems  Top  management  commitment  must  o«  enhanced  and 
funds  must  bo  allocated  to  projects  expected  to  provide 
major  cost-saving  and  operational  benefits  The  GAO 
'•ecoft.mends  to  establish  a  management  structure  for 
standardization  that  includes  a  high-level  sponsor 
accountable  for  supporting  the  J5RC  programs  through  the 
budget  process  determine  whether  funds  for  fiscwl  year 
1934  and  Subsequent  years  should  be  reprogrammed  'o  ensure 
that  joint  standard  avionics  systems  sponsored  by  dSRC  are 
developed  and  available  when  needed  to  meet  candidate 
aircraft  installation  schedules,  and  establish  a  dedicated 
budget  line  item  for  jomt  avionics  programs  The  ODD 
agrees  -ith  the  first  two  recorimendat  ions  but  does  not 
agree  with  th»»  last  nr* 
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UTTc  Ouantum  leap  avionics 

AUTH  A/CANTRELL  W  E  CORP  General  Dynam  i  CS/For  t  Worth,  i  ;< 
Proc  held  >h  Oaytoh.  Ohio,  30  Nov  -  2  Oec  1982  In  ASO 
Rroc  Papers  of  the  2nd  AFSC  Avionics  Sid  Conf  Vo1  -2 
p  959-975  (SEF  N84-31165  21-06) 
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ABS  Current  stanoard’ za t son  levels  in  suc^  programs  as  ♦he 
F-16  are  providing  Oeneflts  of  productivity  and  growth 
that  have  oeen  significant  m  the  success  of  that  program 
The  over • 1 ncreas 1 ng  drive  to  pe.foinance,  multi  use 
systems  and  diverse  weapons  has  heavily  tanea  current 
avionic  resources  In  adOiiion  the  deta  transfer 
requiiement  Is  complicated  by  tre  high  speed  data  flow 
that  modern  computers  both  feed  on  an  produce  by  multiple 
source-mu  1 1 iple  destination  video  distribution 
requirement,  the  need  to  self-test  ti.e  system  to  lowoi 
levels  and  the  desire  to  dynamically  reconfigure  from  <i 
failuie  fortunately  the  technology  to  achieve  solutions 
to  these  new  prob’oms  is  evolving  *n  the  VMSIC  and  fioer 
optics  p'ograms  so  tnat  >t  is  possible  to  r ear  chi tectui e 
the  System  at  the  module  level  as  opposed  to  the  LRU 
level  Module  level  standardization  around  a  small  number 
of  types  allows  a  large  number  of  system  level 
combinations  while  achieving  economies  of  scale  at  the 
module  level  The  usual  ob)ection  to  standardisation  that 
It  freezes  innovation  is  avoided  by  technology 
transparency  provisions  while  at  the  same  time  the 
objection  that  standardi zat ion  obsoletes  the  present  is 
avoided  by  downward  compatibility  provisions  candidates 
for  s tandardi za t ion  in  this  approach  inc<uae  bus 
intei  faces  the  system  network  modules  aril  raews 
RPT«  AD  P003b84  82/11/00  84N3lia9 


UTTL  Standard  aviori'cs  softwar-i  The  fi  ture  strategy  for 
cost-effective  avionics 

AUTH  A/STRAUB.  £  C  CORP  Arinc  Research  Corp  Annapolis 
MO  Proc  held  in  Dayton  Ohio,  30  Nov  -  2  Dec  t982 
In  A'D  Proc  Papers  o*  the  2no  AFSC  Avionics  Std  Conf 
Vo'  2  p  927-945  fS££  N84  -  j  i  it,;,  li-06) 

A£iS  Th'S  paper  reports  an  ARINC  Research  Corporation's  work  in 
developing  and  evaluating  software  acquisition 
alternatives  for  the  uSAf's  Multi-Mode  Raaar  program 
(since  renamed  the  Multi-Role  Rada'-  (Mfift)  Program) 

Although  the  paper  reflects  work  accomplished  for  that 
program  the  approach  taken  could  be  used  for  any 
sof tware- intens 1 ve  avionics  program  where  several  aircraft 
a^e  involved  aro  for  which  most  of  the  software  and 
hardware  might  be  common  The  work  was  sponsored  by  Arr 
Force  Systems  Command's  Deputy  for  Reconna issance  and 
Electronic  warfare.  Aeronautical  Systems  Division 
lASO/RW)  The  paper  assesses  the  applicability  of  current 
radar  technology  and  production  programs  to  an  MRP 
discusses  guidance  provded  by  ens^'ng  ano  proposed 
policies  Directives  ano  Standards  enammes  the 
operational  cost  schedule  risk  supportabi i i tv  ard 
management  aspects  of  throe  software  development 
alternatives  and  addresses  the  use  of  the  ASO/acC' 
software  cost  estimating  model  to  analyze  softwart. 
development  costs  Software  acquisition  alternative 
results  a'-e  prosented 
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UTTL  Fiber  Optics  for  the  future  •  wavelength  division 
miU  1  t  ip1  om  mg 

AuTH  A/SPENCCR  U  L  CORP  National  Aeronautics  and  Space 
Adm in  1  A trat ion  Longloy  Research  Center  Hampton  VA 
Proc  held  in  Oaytor.,  Ohio.  30  Nov  •  2  Dec  1982  In  ASO 
Proc  Papers  of  the  2nd  AFSC  Avionics  Std  Conf  Vol  2 
p  871-888  (SEC  N84-3ii65  21'0i>) 

ABS  Optical  wavelength  division  multiplexing  (WDM)  svstems 

with  signals  transmitted  on  different  wavelengths  throunn 
a  Single  fiber  can  have  increased  information  capacity 
and  fault  solation  properties  over  single  wavelength 
optical  Systems  This  paper  descrioes  a  typical  WOM 
System  The  appl icabi  i  ity  of  future  standards  to  such  a 
System  are  discussed  Also,  a  statc-of*thn  art  survey  of 
optical  multimode  components  which  could  bo  used  to 
implement  the  System  are  made  The  components  to  be 
surveyed  are  scurces  multiplexers  and  detectors 
Emphasis  is  given  to  the  demultiplexer  techniques  which 
are  the  major  developmental  components  m  tn©  wOM  sys  em 
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UTTL  Proposed  MIL-STO  for  avionics  installation 
interfaces 

AUTH  A/SCHOPF  G  CORP  Aeronautical  Systems  Oiv 

Wr ight-Pattei  son  AFB  OH  Proc  held  in  C  /ton  Ohio  30 
Nov  -  2  Dec  1982  In  its  Proc  Papers  of  trie  2nd  afsc 

Avion.es  Std  Conf  Vol  2  p  861-870  (SEE  N84'3tl6b 

21-06) 

ABS  This  paper  describes  the  M*li*arv  Standard  (MIL-STO)  now 
in  development  for  avionics  installation  interface 
s tandard t za t  ion  Origmatl/  based  upon  the  interface 
standard  used  by  the  commercial  airlines,  this  new 
MlL-STO  now  extensively  revised,  is  scheduled  for 
coordination  at  the  end  of  1982  The  background  which  led 
to  the  developraent  of  the  standard  includes  on  analysis  of 
the  benefits  expected  to  result  from  its  application,  the 
relationship  between  rhis  standard  and  other  military 
standi^rds.  and  \t.e  similarities  botween  this  standard  and 
the  commercial  (ARINC  600)  standard  The  open  forum 
approach  using  maximum  industry  participation  was  used 
extensively  over  a  two-year  period  to  produce  the 
document  The  technical  highlights  of  the  standard 
including  weight  and  power  dissipation  limits, 
onv ironmerita  (  requirements  and  LRU  form  factors  are 
presented  A  "lew  electrical  connector,  wh<ch  also  serves 
as  a  hold-dOwn  device,  is  a  key  element  in  the  design 
approach  Air  Force  plans  for  implementation  of  the 
standard  a-e  aimed  primarily  at  new  ai’’fra»es  and  major 
avionics  updates  of  existing  airframes  Also,  those 
avionics  subsystems  beif>g  devripped  for  multiple  airframe 
application  are  prime  candidates 
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UTTL  Optiois  and  opportunities  for  standards  * 
NATO/AGAPD  viewpoint 

AUTH  A/SHEPHERD.  J  T  ,  B/UROAN,  L  d  CORP  MarConi 
Avionics  Ltd  Rochester  (England)  Proc  held  in 
Dayton  Ohio,  30  Nov  -  2  Dec  1982  In  ASD  Proc  Papers 
of  the  2nd  AFSC  Avionics  Stu  Conf  V6l  2  p  843-859 
(SEE  N84-31 165  21-06) 

iflS  This  paper  presents  a  summary  of  the  findings  of  AGARO 
working  Group  06  This  working  group  was  established  to 
consider  Distributed  Micro  Processor  Application  to 
Guidance  &  Control  Svstems  The  results  of  this  study  are 
presented  in  AGARD  AR-i'’8  One  of  the  areas  considered  by 
the  working  group  was  optiori  and  opportuni t les  for 
standards  and  it  is  this  area  that  is  being  considered  in 
this  paper  It  should  be  emphasized  that  this  document  is 
not  intended  to  sungest  definitive  standards  or  even  to 
state  categorically  that  any  given  standard  should  be 
developed  Rather  its  intention  is  to  focus  attention  upon 
tne  need  for  standards  and  to  point  Oat  areas  where 
opportunities  exist  for  staodardi rat  ion  As  will  be  seen 
from  the  p-oviOus  sections  in  this  report  there  is  a  vast 
prol 1 f erat ion  in  hardware  and  software  When  systems  are 
developed  they  often  produce  unique  hardware  and  software 
such  as  operating  systems,  executives  high  level 
languages  etc  Since  the  life  cycle  of  aircraft  systems 
is  at  least  twenty  years  from  conception,  it  could  be  as 
much  as  thirty  years  after  the  initial  design  before  the 
systems  are  finally  phased  out  This  makes  It  almost 
Impossible  to  maintain  avionic  systems  m  the  later  parts 
of  their  1 ife  cycle 
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UTIL  Concepts  for  IMX  avionics 

AUTH  A/SMITH.  R  W  CORP  Army  Aviat’on  Center,  Fort  Rucker, 

AL  Proc  held  in  Ouyton.  Ohio  30  Nov  -  2  Doc  1982 
In  ASO  Proc  Papers  of  the  2nd  AFSC  Avionics  9t0  Conf 
vol  2  p  815-819  (SEE  NS4-3I165  21-06) 

ABS  LHK  is  the  acronym  for  a  family  of  light,  highW  capable 
aircraft  intended  for  operational  use  in  the  pTland 
cattle  well  beyond  the  year  2000  They  will  be  capable  of 
operation  In  a  wide  variety  of  adverse  environments  on  a 
very  hostile  battlefield  (lasers  and  other  directed  energy 
weapons  will  be  commonplere)  Accordingly  the  conceptual 
designs  being  considered  are  Aa-y  different  from  today's 
helicopters  One  .'ajor  thrust  is  toward  automation  of  crew 
duties,  wit*'  a  goal  of  achieving  single  pilot  operation 
RPTw  A0-P003375  82/11/00  84N31180 


UTTl  westingnouse  uses  USAF -oeve i oped  standards 

AUTH  A/SHfMAN  C  S  CORk  Westmghouse  Defense  and 

Electronic  Systems  Center  Baltimore,  mo  Proc  held  m 
Dayton.  Ohio.  30  Nov  •  2  Oec  1982  In  ASO  Proc  Papers 
of  the  2n0  AFSC  Avionics  Std  Conf  Vol  2  p  753  765 
(SEC  fl34-3l  155  21-06) 

ABS  westingnouse  has  applied  digital  standards  advantageous  I  y, 
for  t)ie  u  S  Air  Force  on  its  latest  weapon  systems  At 
present  West ingnouse  'S  applying  MI L -STD- 17S0A  (ISA). 
MIL-STD'  1589B  (JOVIAL  73  HQL  )  and  MK-STO- 1653C 
(multiplex  busing)  to  three  major  programs  B‘l8  Offensive 
Radat  S/Stem  Improved  AN/APG-66  Radar  for  the  F-i6  and 
AFTI  F-16  €iec*ro-Op* 'Cal  Sonsor/Tracker  Westinghouso  has 
gone  one  step  furthe*  than  the  digital  standards  With 
u  $  Air  Forte  encouragement  West mghouse  has  a  program 
for  maximum  radar  commonality  among  the  B-18  ORS  F-15C 
and  *he  U  5  Army  sgt  York  OIVAO  Gun  System  Th's  paper 
will  cover  West  1 nghouse ’ s  approach  toward  manag'ng  the 
application  of  til©  military  standards  across  multiple 
programs  with  different  prime  contractors  and  services 
Mtiditional ly,  the  method  by  which  configuration  control  of 
standard  modulo  hardware  (1  e  .  rational  standardtzat ion) 
maintained  at  Westingnouse  will  be  discussed 
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UTTL  Advanced  cockpit-systems  integration 
AuTH  A/flOE  G  CORP  British  Aerospace  Public  Ltd  Co  . 

Brough  (England)  CSS  (Act  Design  Group  )  Proc  held 
in  Dayton.  Ohio  30  Nov  -  2  Dec  1082  In  ASD  Proc 
Papers  Of  the  2nO  AFSC  Avionics  Std  Conf  ,  Vol  2  p 
695-717  (SEE  N84-31165  21-06) 

ABS  The  present  paper  describes  two  major  complementary 
activities  funded  by  the  United  Kingdom  Ministry  of 
Defense  which  are  being  undertaken  at  the  Brough  site  of 
B’-itish  Aerospace  These  stuc'lea  ate  addressing  the 
problem  of  pilots  ♦a'‘k  optimization  and  the  overal'  system 
architecture  needed  to  meet  the  operational  requirements 
of  the  next  tactical  combat  aircraft  These  activities  are 
the  Advmced  Cockpit  Design  Studies  and  the  Tactical 
Combat  Aircraft  Avionic  Demonstrator  Rig  The  Advanced 
Cockpit  Studies  have  been  underway  for  some  6  years  The 
scope  of  these  studies  has  been  extensive,  covering  escape 
system  design,  g’  alleviation  techniques,  advance  pilot 
and  equipment  cooling  techniques,  information  and  coritroi 
task  rat  tonal  1 zat ion  and  the  developmenf  of  workload 
prediction  ano  measurement  techniques  The  studies  have, 
after  a  number  of  iterations  culminated  in  the 
devtlopment  of  a  dynamic  cockpit  ockup  The  studies 
specifically  related  to  the  information  and  control  task 
rat  Iona  1 1 zat Ion  will  be  discussed  in  this  paper  m  some 
detail  The  Tactical  Combat  Aircraft  Avionlr  Dehonstrator 
Rig  is  presently  at  the  mid  point  of  a  3-4  year 
evolutionary  design  program  invest 1 jat lng  such  topics  as 
total  system  integration,  standardization  of  interfaces, 
iffective  sub-system  intei  communication,  graceful 
degradation  of  the  system  and  improvad  maintenance 
procedures  The  arcti i lecture  being  developed  has  a  multi 
bus  hierarchy  and  impUments  the  data  transmission 
standard  15538  for  sub  system  to  sub  syatoci  and  bus  to  bus 
communicet ions 

RPT*  T0-P003569  82/11/(30  84N31174 


R-15 


UTTl  Integr'ated  te'iting  ana  maintenance  tecnnologte* 

AUTH  A/DtNNEV  R  C  G/PAR  .'R  fOGE ,  M  o  .  C/WlLLIAMS,  R  8 
CORP  Booing  Aerospace  Co  Seattle  WA 
AB^  Maintenance  of  weapon  systems  is  becoming  an  increasingly 
important  cars lOnrat ion  in  weapon  system  development 
because  the  cost  of  maintenance  is  a  significant  portion 
of  tne  life  cvcie  cost  of  the  system  The  objective  of  the 
Integrated  Testing  and  Maintenance  Technologies  effort  is 
to  def'ne  requirements  for  an  onboard  test  system  for  the 
avionic  Suite  planned  for  tactical  fighters  In  the  1990's 
Problems  with  current  onboard  test  systems  were  ana.yzed 
to  determine  where  ‘mprovoments  coulj  be  made  In 
addition,  the  anticipated  avionic  architecture  and  mission 
of  tne  i990‘s  were  evaluated  to  determine  the  impact  on 
naintenance  capability  Roquir»raents  for  the  Integrated 
lesting  and  Maintenance  S''Stem  «ere  developed  and 
documented  in  a  system  specification  Identified 
improvements  over  current  systems  include  better  filtering 
of  intermittent  failure  reports  tetter  iso.ation  of 
intermittent  failures  through  ti’e  use  of  recorded  data 
mere  extensive  use  uf  system  level  tests  of  mission 
operational  data  and  a  man-machine  interface  providing 
more  information  to  the  maintenance  technician  In 
addition,  artificial  mte .  l  igerice  applications  were 
evaluated  to  determine  where  they  might  be  effectively 
applied  to  ITM  A  design  concept  for  a  fauit 
classification  expert  system  was  developed 
RPT«  AO-Al3aS87  AFWAL - TR - 62 -  1 183  83/12/00  84N22528 


UTTL  Multibus  Avionic  Architecture  Design  <:tudy  (MAAOS) 
AUTM  A/RICM,  B  A  B/HALOEMAN  0  C  .  C/STAOIBERC  0  t 
0/WHALEN  w  P  CORP  TRW  Oefense  and  Space  Systems 
Group  Redondo  Beach,  Ca 

ABS  The  Multibus  Avionic  Architecture  Design  Study  (maaoS) 
evaluated  projected  avionic  requirements  for  tactical 
aircraft  of  trie  1990s  ana  definef*  an  arcni  tec*ural 
approach  and  design  example  suitable  for  use  as  the 
baseline  for  tne  Avionic  System  Integration  Demonstrator 
(ASIOi  System  Definition  project  The  arrt.itecturai 
approach  is  multi  bus  m  nature  including  MH-STO- 15536 
bus  a  h-gn  speed  bus.  and  a  video  bus  System  sizing  and 
timing  estimates  are  provided  Areas  fo*"  potential  future 
standaraizat ion  are  identified 
RPTx  A0-A138226  AFWAL-TU  82-1141  89/10/00  84N21546 


LTTL  Automated  data  base  imp.ementat ion  requirements  for 
the  avionics  pian-iing  baseline.  Army 

AUTM  A/5Pt«AT0.  M  G/MEAO.  fi  CORP  Anne  Research  Coi-p 
Annapolis.  MO 

ABS  The  U  S  Army  Avionics  Research  and  Development  Activity 
intends  to  establish  the  use  of  the  Avionics  Planning 
Basel  ine-Ai  ffly  tAPB-Aj  document  a'l  an  important  facet  of 
the  formal  avionics  planning  process  The  APB-A  was 
designed  to  maintain  maximum  compatibility  in  both  form 
and  content  wth  similar  avoinicS  planning  documents 
puDlisried  by  tne  Air  Force  and  the  Navy  This  overall 
compatibility  should  facilitate  the  exchange  of 
information  among  the  three  services  for  tne 
tdent 1 f icat ion  of  avionics  standardization  opport jni t *es 
The  first  edition  of  the  APB-A  was  the  product  of  the 
collection  and  manusl  assembly  of  avionics  planning  data 
for  current  and  future  planned  Army  aircraft  into  a  report 
format  Similar  to  that  of  the  Air  Force  Av  nmes  P  anning 
Baseline  and  'he  Navy  Avionics  Planning  Gase'ine  This 
techiiica  report  addresses  the  requirements  for 
implementing  an  automated  version  of  the  Army  avionics 
data  base  compatible  with  existing  Air  Force  and  Navy  data 
base  archl  tectures  and  capable  of  m-ocnanizing  the 
production  of  the  aP6-a  The  coivpiete  automatec*  system 
Will  be  documented  m  a  futur'e  report 
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UTTi  USAF  (United  States  Air  Force)  avionics  n»a*'*er  plan 
CORP  Oepartpnent  cf  the  Air  Force  Washington.  DC 
ABS  This  IS  the  fourth  annual  USAF  Avionics  Master  Plan  lAMFl 
It  15  prepared  by  the  Deputy  for  Avionics  Control  as 
directed  in  afR  800-28.  Air  force  Policy  on  Avionics 
Acquisition  and  Support  The  purpose  of  the  plan  is  to 
serve  as  a  guide  to  tne  avionics  community,  to  focus 
resources  and  energies  on  rommon  goals,  and  promulgate 
Strategies  to  move  toward  the  resolution  of  common 
problems  Strong  emphasis  continues  in  the  avionics 
programi  a-eas  of  tactical  and  strategic  C3.  electronic 
combat  and  target  acqu i s i • lon/recognl t ion  from  the 
standpoint  of  improved  near/mid  term  capability  Programs 
supporting  these  areas  aro  procevding  essentially  as 
previously  planned,  with  the  exception  of  tactical  C3 
Significant  changes  are  being  planned  in  the  approach  to 
achieving  jam  resistant  communications  The  alternative 
architecture  to  be  selected  (scheduled  for  review  and 
approval  In  the  near  future)  could  impact  the  JTIOS  and 
Marx  XV  IFF  programs  as  well  as  SEEK  TALK 
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uiit  lowaros  a  veritable  supervisor  program  for  avionics 
sof  tware 

AliTH  A/BRACON,  G  CORP  f  1  ec tron ique  Serge  Dassou 1 1 .  Saint 
Cloud  (France)  In  AGARO  Software  for  Avionics  14  p 
(SEE  N83-22112  12-00 

ABS  experience  acquired  m  the  development  of  equipment  and 
avioi.ics  software  for  the  Mirage  F)  and  the  Mirage  2(X)0. 
led  tc  the  definition  of  a  software  overseer  The  ajglE 
supervisor  program  1S  oriented  toward  considering 
methodologies  and  assists  m  developing,  rsalntainlng,  and 
following  the  project  It  involves  a  group  of 


complementary  operational  tools  which  use  a  central  data 
base  and  can  tneri  divide  the  information  The  integration 
of  official  service  and  tno  comfort  of  man  machine  dialog 
permits  improved  oroductiyity  The  essential 
character i St 1CS  of  AIGLE  is  the  automatic  knowledge  of 
quality  control  information  and  of  project  management 
This  permits  validation  of  production  processes  an 
indispensable  element  m  software  certification 
83/01/00  83N22I16 


uTTL  Advanced  aviomc  systems  for  mul  t  imi ss  ion 
applications  volume  2 

AUTH  A/SMI TH.  L  A  B/BEHNEN.  S  W  C/PRATT  K  0 

0/MCCALL  M  B  E/BOUSLE*  R  F  CORP  Boeing  Mil Itary 
Airplane  Development.  Seattle.  WA 

ABS  This  study  produced  system  control  procedures  and 
executive  software  design  specifications  for  three 
different  information  transfer  systems  (ITS)  each 
designed  to  implement  multimisslon  aspects  cf  an  avionic 
system  The  stationary  master  is  the  best  understood  ITS 
and  has  multimisslon  advantages  if  tne  applications 
software  is  designed  for  change  The  non-stat lonary  master 
is  an  excellent  candidate  for  a  pod-onenteo  multimission 
application  The  contention  access  ITS  's  designed  to  do 
most  flexible  in  terms  o*  change,  at  the  potential  cost  of 
higher  initial  integration  checkout  due  to  the 
asynchronous  nature  of  the  communicat ion  A  second  task 
was  to  design,  develop  and  build  a  cor.pact  version  of  the 
DAIS  executive  that  would  function  in  a  one  processor 
system  and  support  only  synchronous  bus  communicat .ons 
This  executive,  called  the  Single  Processor  Synchronous 
Executive  (SPSE)  was  tested  and  delivered  to  aFWAL  The 
primary  goals  of  this  task  were  to  build  a  functional 
executive  that  Maintains  the  DAIS 

execu 1 1  VO* to-appl icat ions  interface  Communicates  on  a 
MR-ST0-1553A  bus  Is  coded  ‘n  J73/I  5->pports  the  avionic 
system  load  for  an  AMST  or  modern  tactical  fighter 
aircraft  uses  DAIS  support  "Oftware  (LINKS  ALAP 
PALEFAC  PALffAC  processor)  and  Requires  substant i a l 1 y 
less  memory  than  tne  baseline  DAIS  executi''e  All  goals 
were  achieveo 

RPT*  A0-A12W94  AFwAL-Ttt-82-1076-V0L-2  82/10/120  0JN1975O 


UTTL  Development  of  avionics  installation  interface 
standards 

AUTM  A/BAILCY  $  6/5ULL1VAN  N  .  C/SAVISAAR  A  CORP 
Arinc  Research  Corp  Annapolis  mo 

AOS  This  report  Summarizes  ARINC  Research  Corporat lon ' s 
efforts  under  Air  Force  Contract  F04606-79-G-0082 
“Standard  Rack-Mounted  ano  Panel -Mounted  Avionics 
Interfacs  Concepts  Analysis  '  The  period  of  performance 
was  29  August  1980  through  15  June  1981  Tne  technical 
areas  addressed  ware  tne  analysis  ano  potential 
spec  1 f icat ion  of  rack  mounted  avionics  cockpit  mounted 
control  panels,  and  pane  1 • mounted  instruments  Contract 
tasks  included  conceptual  studies  of  potential 
conf  igurat  ions  of  a  Standard  Avionics  Integraloci  Control 
System  (SAICS)  The  results  Of  the  SAICS  analyses  aro 
reported  separately  m  #tfJNC  Research  Pubi‘cation 
2258-02  1-2439  tost  Benefit  and  Failure  Critical 'ty 
Analyses  of  *ne  Standard  Avionics  Integrated  Control 
System  (SAICS)  Concept,  June  1981  The  concepts  analysis 
prejeci  described  herem  continues  a  contractual  effort 
initiated  by  the  Air  Force  in  1979  to  tfetermine  whether  a 
comprehensive  Packaging,  Mounting,  and  Environmental  (PMEI 
avionics  interface  standard  would  oenetlt  Air  Force 
aircraft  Comprehensive  findings  of  that  effort  are 
documented  in  ARINC  Research  Publication  1753-01  * i * 2 124 , 
Standard  Avionics  Packaging  Mounting  and  Coolirig 
Basel  ir'e  Study  January  1980,  which  addresses  the 
applicability  of  commercial  airline  avionics  to  military 
aircraft,  the  cost  benefits  associate^  with  Air  Force  PME 
standards,  and  a  possible  implementation  scenario  witti 
recommended  activities  and  schedules 

RPTx  AO-All6a52  RCPT-2258-03-2-247'’R  8  /08/00  83N11123 


UTTL  Integrated  control  of  mecnanical  system  for  future 
combat  aircraft 

AUTM  A/WlLCOCK  G  W  B/LANCASTER  P  A  C/MOXEY  C 

CORP  Royal  Aircraft  Establishment  Farnborough  (England) 

.  British  Aerospace  A1-craft  Group,  warton  (England) 

In  AGARO  Tactical  Airborne  Distributed  Computing  and 
Networks  16  p  (SEE  N82- 17086  08-01) 

ABS  Various  techniques  for  the  application  of  digital  control 
to  aircraft  utility  systems  were  investigated  It  is  shown 
that  the  pr^fered  approach  utilizes  a  number  of 
distributed  processors  and  terminals  that  interface  with 
the  utility  comfonents  Analysis  performed  to  data  shows  a 
weight  saving  of  approximately  100  Kg  (i  e  50%)  and  a 
pilot  workload  reduction  of  the  order  of  4  1,  may  be 
achieved  in  a  twin  engine  combat  aircraft  81/10/00 
82N171 W 


UTTt  Techniques  for  Inter fac ing  mul t iplex  systems 
AUTM  A/GROSS  J  P  CORP  SCI  Systems  Inc  .  Huntsville  al 
ABS  Data  ooscribing  the  characteristics  of  a  number  of 

aircraft  multtr.lex  vnwn  co’ I'-ctcd  end  ccTp  led 

Although  Air  Force  aircraft  received  priority,  were 
consiaerat ion  was  also  given  to  other  military  and 
commercial  aircraft  ThO  F-16  6-52  OAS.  VAH-6-  F-18 

F-i5  and  ARINC  575  systems  were  included  MiL-STD- 15S3S 
was  used  as  a  baseline  foi  comparison  The  compiled  data 
was  analyzed  to  deter/ririe  pemts  of  incompatibility 
between  these  systems  and  a  feasibility  study  was 
performed  to  assess  possible  techniques  to  be  used  m 
achieving  bus  compatibility  A  programmable  mter'ace 
module  design  philosophy  is  recomoendod  which  utilizes  a 
distributed  three-m icrqprocessor  an angement  to  achieve 


IM() 


the  desired  interface  compat »Bi J > ty  The  three-processor 
conept  allows  tnree  independent  software-controlled  events 
to  occur  simultaneously  thus  providing  an  extremely  high  ABS 

degree  of  flexioility  Doth  for  existing  systems  and  for 
future  growth 

RPT#  iD-A101457  AFWAC-TR  80-1223  81/02/00  82N13135 


UTTL  A  standard  control  display  unit  for  mul t i -a ircraf t 
appi icat  ton 

liTm  A/SWASSON,  R  L  e/SCOUGTON.  C  »  CORP  Collins  Radio 
Co  Cedar  Rapids.  lA  CS^  (Gove,  nment  Avionics  Div  I 
In  aGaRO  Tne  Impact  of  New  Guidance  and  Control  Systems 
on  Mil  Aircraft  Cockpit  Qesign  10  p  (^£t  N82-13048 
04*01 1 

ACS  the  need  for  standardization  of  military  hardwnre  u  w»ll 
documented  Doth  within  the  u$  000  and  ^Ar 
Standardi zat  ion  issues  rnvol*”  .on  ly  arcvjnc 
interoperaDi I  1 ty  logistics,  and  I'/o-cyc''  cost 
advantages  The  issue  of  standardization  and  its 
.uitabillty  in  the  design  of  aircraft  controT/dispiay 
units  (COU)  is  addressed  Potential  Denefit^, 
requirements,  and  remaining  proDlems  associated  with 
standardization  of  avionics  control  displays  are 
discussed  included  is  a  discussion  of  a  COU  that  is 
currently  oeuig  produced  which  has  many  o*  tno  features 
considered  essential  to  the  ultimate  standard  CDu 
81/08/00  82N1305<t 


UTTL  Actual  versus  simulated  equipment  for  aircraft 
maintenance  tra.ning  Cost  UAp i teat  Ions  c*  the 
incremental  versus  the  unique  device 
AUTM  A/VESTEWIG  R  ^  .  B/EGGEMEI£fi.  F  T  CORP  Air  force 
Human  Resourcos  Lab  .  Brooks  AFB.  TX  CS$  (togistics 
and  Technical  Training  O’v  )  Tresented  at  tne  23rd  Ann 
Meeting  of  the  H.^man  Factors  Soc  .  1979 
ABS  Life  Cycle  cost  estimates  were  developed  for  use  of 

simulated  test  equipment  vs  actual  test  equipment  in  a 
maintenance  training  program  of  th^  lype  used  for  current 
advanceo  fignter  aircraft  Previous  life  cycle  cost 
comparisons  had  not  exolicitly  co'Sidered  the  cost 
implications  of  procurement  and  support  of  a  unique 
training  device  vs  an  incremental  device  This  effort 
included  the  unique  vs  the  incremental  device  factor 
Total  estimated  fifteen  year  costs  for  simulated  eqjipment 
trainers  were  s igni f icant ly  lower  than  comparable 
estimates  for  actual  equipment  trainers  The  results 
mdicfte  that  tno  cost  implication,,  of  a  unique  device  vs 
an  incremental  device  are  -mportant  determinants  of  both 
acquisition  and  support  cost  estimates  ana  should  be 
considered  fully  in  future  life  cycle  costing  efforts 
fiPTw  A0*A102388  AFMRL-TP-81-  17  81/07/00  81N31104 


UTTL  Airborne  Systems  software  Acquisition  Engineering 
Guioebook  for  application  and  use  of  tne  guidebooks 
( series  overview) 

AUTh  a/PARRIOTT  l  CORP  TRW  Uefensc  and  space  Systems 
Croup.  Redondo  Beach  CA 

A6S  ''his  guidebook  serves  as  an  introduction  to  the  Airpome 
Systems  Software  Acquisition  Engineering  guidebook  senes 
which  describes  significant  activities  and  events  m  the 
software  acquisition  life  cycle  of  airborne  emoedded 
computer  systems  acquired  within  the  framework  of  Au 
Force  800-serie3  documents  This  guidebook  contains  a 
brief  description  of  the  other  fifteen  guidebooks  and 
discusses  the  application  and  use  of  the  various 
guidebooks  during  the  acquisition  o*  embedded  weapon 
system  software 

HPTk  A0-A1OO216  TRW- 30323 ■ G003- Tu-00  ASO-TR -80-5028  80/10/00 

81N28787 


UTTL  Airborne  Systems  Software  Acquisition  Engineering 
Guidebook  for  software  cost  analysis  and  estimating 
AUTH  A/WOLVERTON,  R  W  CORP  TRW  Defense  arKi  Space  Systems 
Group  Reoondr.  Beacn  CA 

ABS  This  guidebook  .issists  Air  Force  Program  Office 

engineering  and  management  porsonnel  In  costing  embedded 
software  for  avionics  applications  a  methodology  tor  cost 
reporting  and  avoiding  the  '90  percent  complete'  syndrome 
IS  presented  An  annotated  bibliography  gives  the  author's 
personal  view  of  source  material  relevant  to  avionics 
software  costing  using  modern  programming  practices 
RPT»  AD-A100215  TRW-30323-6012-TU-00  ASO-TR-80-5025  80/09/00 

81N3878S 


UTTL  Predicting  co5t/rel iabi 1 1 ty/naintaioabl 1 1 1 y  of 
advanced  general  aviation  avionics  equipment 

AUTH  A/OAVIS  M  R  .  B/KAMINS  M  ,  C/MOOZ.  W  E  CORP  RANG 
Curp  ,  Santa  Monica,  CA 

ABS  A  methodology  is  provided  for  ^slsting  NASA  in  estimating 
the  cost  reliability,  and  maintenance  (CRMi  r-oryitrniMnn*^ 
for  general  avionics  equipment  operating  in  the  i980'u. 
Practical  problems  of  predicting  these  factors  are 
examined  The  usefulness  ang  stw-rt  comings  of  different 
approaches  for  modeling  coast  and  reliability  estimates 
are  discussed  together  w  th  special  problems  caused  by  the 
lack  of  historical  data  nn  the  cost  of  maintaining  general 
aviation  avionics  Suggestions  are  offered  on  now  NASA 
night  proceed  in  assessing  cost  reliability  CRM 
Implications  in  the  absence  of  reliable  generalized 
predictive  models 

RPTW  NASA-CR- 182149  RANO/WN- 10233-NASA  78/06/00  8tNI91t1 


UTTL  Summary  of  AG«R0  ( eCture  Series  10*0  Mernodology 
for  control  of  life  cycle  costs  for  avionics  systems 
AUTH  A/GA6ELMAN.  I  0  CORP  Gabelman  (Irving  U  )  Tocnnical 

Associates.  Rome  Nv  Lecture  held  in  Bonn,  ;-8  May  1979 


and  in  Athens  iO-lt  May  1979  In  AGARO  Design  to  Cost 
and  Life  Cycle  Cost  8  p  (SEE  N81-11902  02-81) 

The  continually  increasing  cost  of  avionics  and  we.spons 
systems  between  aquisition  and  their  lifetime  operation 
are  discussed  Specific  emphasis  is  given  to  tne 
following  elements  of  life  cycle  costs,  parametric  cost 
analysis,  and  life  cycle  cost  methodology  80/0^/00 
8  IN1 1924 


UTTL  Design  to  life  Cycle  costs  imeract  ion  of  engine  and 
a  ircraf  t 

AUTM  A/dONES.  £  J  CORP  Ministry  of  Defence.  London 

(England)  In  AGARO  Tie  Appi  of  Design  to  CO^t  ana 
Life  Cycle  Cost  to  Aircraft  Eng  15  p  (SEE  N80'3l^42 
22-01) 

ABS  The  distribution  of  life  cycle  costs  for  a  typiCal  combat 
aircraft  between  airframe  avionics  and  engine  ’s 
discussed  Distribution  of  costs  for  the  aircraft  between 
development  production  initial  support  ana  openation  and 
support  IS  compared  with  the  distribution  for  th®  engine 
The  effect  of  fleet  size  and  service  life  upon  the  life 
cycle  costs  are  indicated  The  large  commitment  of  life 
Cycle  costs  early  in  the  conceptual  and  feasibility  phase 
of  the  program  is  indicated  The  choice  of  engiiie  is  an 
example  of  this  early  commitment  The  relative  effect  of 
the  choice  nr  single  or  twin  engine  installation  of  a 
derated  engine  or  the  use  cf  an  existing  engine  upon  the 
engine  life  cycle  costs  and  the  interaction  with  aircraft 
costs  IS  discussed  The  severe  operating  conditions  for 
the  engine  of  a  combat  aircraft  are  reviewed  Reduced 
Support  costs  are  not  exoectod  to  give  a  large  fold  return 
on  extra  engine  development  investment  80/05/-rO 
BON31344 


OTTl  Standard  avionics  parKaging  mounting  and  cooling 
base!  me  study 

AUTh  A/BAILY  S  .  B/dACkSON.  A  C/fiU5S£LL  0  D/SMITH  C 
N  D  E/SULLIVAN  N  CORP  Ar me  Research  Co^P 
Annapolis  MO 

ABS  This  IS  the  final  report  on  a  $»udy  concerning  the 
development  of  an  avionics  packaging,  mounting,  and 
environmental  (PME)  standard  and  an  associated 
cost-benefit  analysis  Tne  report  compares  military  arid 
commercial  airlines  avionics  generic  standards  to 
determine  tneir  technical  «na  procedural  differences  and 
Identifies  the  changes  i na  waivers  required  when  equipment 
built  to  the  commercial  airlines  standards  a  o  procured  by 
the  USAF  It  also  compares  the  functional  ano  physical 
characteristics  of  certain  military  and  commercial 
avionics  equipments  and  assesses  tfie  degree  of  utility  of 
Current  commerc'd!  equipments  for  use  m  uSAF  aircraft 
The  opinions  of  aircraft  and  avionics  manufacturers 
concerning  a  military  avionics  PME  standard  ancj  their 
sugges'ions  as  to  what  the  standard’s  scope  an 
applicability  should  be  are  reported  Ai ternat ive 
avionics  cooling  procedures  ana  technologies  and  the 
concept  of  employing  a  separate  environr.ontal  control 
syste'A  dedicated  to  avionics  coon.-ig  are  reviewed  A 
life-cyde  cost  payback  model  that  addresses  the  impact  uf 
PME  stanaardizat ion  on  the  cost  of  avionics  systems  m 
u>AF  aircraft  is  described  The  results  of  exercising  the 
model  are  reported  The  significant  tasks  and  scheduling 
for  "he  next  phases  of  avionics  PME  development  leading 
to  tne  definition  and  acceptance  of  a  military  avionics 
PME  standard,  are  presented 

RPTw  A0-A082166  REPT -  1753-01  - 1 -2  l24  80/01/00  80N24JI2 


UTTL  Reliability  management  of  the  avionic  systifm  of  a 
military  strike  aircraft 
AUTH  «/WHITE,  A  P  .  B/PAVIER  d  0  CORP 

£  1 1  tot t -Automat  ton  Space  and  Advanced  Military  Systems 
Ltd  ,  Camberiey  (England)  In  AGARO  A/ionics 
Reiiabii  ty  Its  Tech  and  Related  Disciplines  i3  p  (SEE 
N80-19519  10-33) 

ABS  The  system  management  techniques  to  achieve  the 

reliability  requirements  for  the  avion'c  system  of  the 
Panavia  Tornado  aircraft  are  described  The  method  of 
•■O' 'rt lonment  of  these  requirements  to  each  of  th® 
■'•tituent  parts  of  the  system  is  explained  The  aims 
effectiveness  and  experience  to  date  of  reliability 
w.-onstrat  Ions  are  ou' lined  79/10/00  80N19546 


UTTL  Military  adaption  of  a  commercial  VOR/ILS  airborne 
radio  with  a  reliability  improvenient  warranty 
AUTH  A/FEOER  E  I  B/NlEMOtLER,  D  L  PAA  B/(8of'dlx 

Corp  fort  Lauderdale,  Fla  )  CORP  Army  Avionics 
Research  ana  Development  Activity  Fort  Monmouth,  NO  In 
AGARO  Avionics  Rcl  i.'D’ 1  1  ty .  Its  Tech  and  Related 
Disciplines  8  p  (SEE  N80-19519  10-38) 

ABS  Low  cost,  small  lightweight  airoorne  naviqatlon  raceweis 
were  acquired  and  reconfigured  to  meet  U  S  Army  aircraft 
specifications  The  contract  includes  a  clause  requiring 
the  manufacturer  to  assume  responsibility  for  the  field 
reliability  and  repair  of  each  receiver  for  a  minimum  of 
four  years  If  successfully  imple.mented.  the  reliability 
improvement  warranty  should  increase  reliability, 
availability,  and  maintainability  and  reduce  the  overall 
equipment  life  cycle  costs  79/10/00  80N19540 


UTIL  Impacts  of  technologies  selected  on  the  reliability 
and  operational  availability  of  equipments  Cost 
cons iderat ions 

AUTM  A/GIRARo,  J  M  .  B/GIRAUO  M  CORP  Eloctronique  Marcel 
Dassault  Saint  Cloud  (France)  In  AGARO  Avionics 
Reliability,  Its  Tech  and  Related  OisclpMnos  17  P  (SEE 
N80'19519  10-38) 

AbS  A  single  criterion,  v.  is  proposed  to  allow  manufacturers 
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to  evaluate  the  merits  of  technological  variants  once  an 
equipment  baseline  version  is  designed  and  quoted  The  V 
factor  »s  computed  for  an  airborne  digital  con»?utor.  a 
Doppler  navigational  radar,  and  a  search  and  rescue 
beacon,  each  considered  In  tl  ree  different  versions 
T9/ 10/00  80N19536 


UTTL  A  method  for  designing  mul t iprocessor  architectures 
for  avionics  functions 

A/ALCONARO,  C  .  B/OIHOMCNT  A  C^ROMAM).  P  .  O/GILLON. 
d  ,  6/lEMAITRE.  J  F  PAA  D/<CERT  Toulouse.  France) 
F/(CERr,  Toulouse  France)  CORP  Societe  Crouzet, 

Valence  (France)  In  AQARO  Advan  in  Guidance  and 
Control  Systems  Usirg  Digital  Tech  7  p  (SEE  N80-140I7 
05-01 ) 

A  digital  technique  is  given  for  the  design  of  high 
performance  automatic  s/stems  Tne  evolution  of  digital 
techniques  preserts  the  automatist  with  the  problem  of  the 
total  design  of  a  control  system  It  moans  going  beyond 
algorithmic  synthesis  from  the  beginning,  to  take  into 
account  all  the  functional  ana  operational  aspects  Thus 
It  Is  possible  to  optimize  the  control  system  according  to 
three  important  criteria  regard  for  the  desired 
operating  performances,  the  total  cost,  and  the  very 
important  matter  of  operational  safety  (reliability, 
security,  ma 1 nta 1 nabi I i ty .  and  aval labi 1 1 ty )  79/Od/OO 
80N 14021 


UTTl  Avionics  standardizat *on  potential  analysis 
A/GATES.  R  K  8/SHlPP.  R  F  CORP  Analytic  Sciences 
Corp  Reading,  ma 

The  objective  of  the  Avionics  Standardization  Potential 
Analysis  program  is  to  develop  a  general  methodology  for 
evaluating  the  benefits  accruing  from  the  use  of  standard 
equipment  across  future  u$AF  avionics  systems  The 
methodology  has  been  developed  using  navigation  avionics 
as  being  representat ive  of  avionics  in  general,  in  a  study 
Of  standardization  potential  across  navigation  systems 
(SPANS)  The  methodology  covers  the  process  of 
establishing  future  avionics  Systems  requirements  through 
mission  analysis,  ident if icat ion  of  available  equipment 
for  the  design  of  mfssion-responsive  avionics  suites, 
evaluation  of  future  qujntitative  demands  for  avionics 
equiprtent.  synthesis  of  mission-capable  avionics  systems 
collection  of  relevant  cost  ana  reliability  data  ano 
evaluation  of  standardizat ton  options  using  a 
computer -based  Standardizat ion  C/aiuatton  Program  iSTEP) 
A0-AO66138  TASC-Tfe-t059-3  AFAL-Tfi'70-I68  78/11/30 
79N239S8 


UTTl  Modular  Avior  cs  Packaging  (MAP*  COPP  General 
Electric  Co  Utica,  Nv  CSS  (Aircraft  Equipment  D'v  ) 
In  considering  Modular  Avionics  Packaging,  the  oujective 
of  tne  General  Electric  study  program  was  to  develop  an 
avionics  eguipmerit  packaging  concept,  compatible  with 
Mli-E-5400  and  applicable  to  multiplatform  avionics 
requirements  stretching  into  the  i990's  Specific  elements 
evaluated  were  Standard  Avionics  Module  (SAM) 
reqviirements  and  concepts  integrated  racks  and  MRA 
requirements  and  concept*!,  arid  airframe  interface 
considerations  Tne  v/STOL  Type  A  piatforis  was  used  as  the 
driving  requirement  m  performing  traoe*off  studies  Key 
design  objectives  and  constraints  included  the  following 
Minimizing  installed  avionics  weight  and  volume 
Mechanical  simplicity.  Significant  improvement  in 
Reliability  snd  Maintainability.  Eliminating  single-point 
failure  modes.  Direct  access  to  Weapons  Replaceable 
Modules  (WPM),  Modules  capable  of  being  corduction-cooied 
Significant  improvement  in  thermal  performance,  and 
Improved  testability  at  all  hardware  levels 
A0-AO59637  77/11/30  79N14093 


UTTL  The  Avionics  Laboratory  Predictive  Operations  and 
Support  (ALPOS)  cost  model  .volume  3 

A/TUREK.  0  P  .  B/WIENECKC  E  L  III.  C/FfLTUS  E  E 
CORP  Westinghcuse  Electric  Corp  .  Hunt  Valley,  MO 
Recent  000  experience  shows  that  a  prime  factor  in  the 
evaluation  of  alternative  weapon  systems  for  performing  ^ 
particular  mission  is  Life  Cyde  Cost  (lCC)  Since  70%  of 
tne  system  LCC  is  determined  by  the  end  of  the  conceptual 
phase.  It  is  important  that  techniques  to  predict  LCC  be 
available  during  that  pi<as«  Since  system  definition  is 
not  complete  enough  in  this  phase  to  perform  detailed 
analysis  using  accounting  models,  the  major  tool  which  can 
be  used  is  parametric  estimating  models  This  report 
-^escribes  a  model  which  relates  the  available  design 
parameters  to  LCC  via  various  cost  estimating 
relat  lonships  (CERs)  This  docu.<ient  Is  Volume  3  of  the 
Final  Report  which  describes  the  consolidated  data  ba^e 
utilized  to  develop  the  Avionics  Laboratory  Predictive 
Operations  ana  Support  (ALPOS)  cost  model  The  Air  Fnrro 
riugram  Monitor  was  '.t  Thomas  T  James.  Or  {AFAL/AAA-3). 
System  Evaluation  Group,  Avionic  Systems  Engineering 
Branch 
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UTTl  Report  on  Modular  Avionic  Packaging  (MAP)  industry 
briefing  and  response 

A/KIOWELL.  0  R  CORP  Naval  Avionics  Center. 
Indianapolis.  IN 

This  report  provides  information  related  to  a  rpodular 
avionic  packaging  (MAP)  concept  presented  to  industry  on  9 
May  1978  at  the  Naval  Avionics  Center  Indianapolis 
Indiana  In  attendance  at  this  leettng  were  78 
representat Ives  of  different  divisions  of  33  companies  As 
major  suppliers  of  avionics  to  the  Navy  comments  provided 
by  these  companies  were  anticipated  to  be  vary  useful  in 


the  further  develc-pMCnt  of  packaging  approaches  for  future 
a\  ionics  This  re''C''t  contains  the  responses  provided  by 
industry  Although  the  companies  responqtng  are  identified 
by  name  for  reference,  a  reasonable  attempt  has  been  made 
to  render  the  comments  anonymous  by  removing  company  names 
and  product  references  The  comments  have  been  grouped 
into  categories  and  summarized,  however,  no  attempt  has 
bee  "..ide  in  this  report  to  resolve  areas  of  confiic.ing 
opinion  given  by  different  companies  It  15  not  intended 
to  imply  that  the  Navy  on  this  Center  endorses  agrees,  or 
disagrees  in  any  manner  with  the  comments  provided  by 
industry 

RPT4  A0'AO59193  NAC-TR-2240  78/08/09  79N13039 


UTTL  The  feasibility  of  estimating  avionics  support  costs 
early  in  the  acquisition  cycle  Volume  2  Appendixes 

AUTH  A/MORGAN,  d  0  ,  B/FULLEH,  A  B  CORP  Institute  for 
Defense  Analyses.  Arlington.  VA  CSS  (Cost  Analysis 
Group  ) 

ASS  This  paper  reports  on  research  to  determine  the 

feasibility  Of  developing  methods  to  estimate  early  in 
the  system  acquisition  cycle  the  potential  support  cost 
inputs  of  alternative  avionics  components  envisioned  for 
Air  Force  and  Navy  flgntor  aircraft  Suppc"t  costs  are 
defined  as  those  costs  incurred  at  the  urgani zat i ona i 
intermediate  and  depot  levels  to  maintain  avion'cs 
equipment  and  the  costs  of  avionics  spares  and  repair 
parts  Support  Volume  2  Is  a  compilation  of  appendixes 
containing  additional  material  to  support  the  basic 
report,  including  summary  evaluations  of  forty  eight  key 
documents  encountered  In  the  literature  search 

RpT#  A0-A053486  AD-£5(XX)26  P-i292-V0L-2  IDA/MQ - 77 -  19873 
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UTTL  General  aviation  avionics  equipment  maintenance 

AUTH  A/PARKER.  C  D  .  B/TOMMERDAHL  J  S  CORP  Research 
Triangle  Inst  Research  Triangle  Park.  NC 

ABS  Maintenrnce  of  general  aviation  avionics  equipment  was 

investigated  with  emphasis  on  single  engine  and  light  twin 
engine  general  aviation  aircraft  Factors  considered 
include  tne  regulatory  agencies  avionics  manuf acturers , 
avionics  repair  stations  the  statistical  character  of  the 
general  aviation  community  and  owners  and  operators  The 
mamienanre.  environment  and  per  formance.  repair  costs, 
and  reliability  of  avionics  were  defined  It  is  concluded 
that  a  significant  ecor>omic  strat  i  f  icat  ion  is  reflected  m 
the  maintenance  problems  encountered,  that  careful 
attention  to  installations  and  use  practices  can  have  a 
very  positive  impact  on  maintenance  problems  and  that  new 
technologies  ano  a  general  growth  in  genera'  aviation  will 
impact  maintenance 

RPT*  NA$A-CR-145342  RTI- id64-00-CfOF  78/05/00  78N2413? 


UTTl  Preliminary  candidate  advanced  avionics  system  for 
general  aviation 

AUTH  A/MCCALLA,  7  M  .  B/GRISMORE  F  L  C/GREATLINE  S  E 
0/81RKHEAD  L  M  CORP  University,  of  boufhorn  Illinois 
Carbondaie 

A6S  An  integrated  avionics  system  design  was  earned  out  to 
tne  level  which  indicates  subsystem  function  and  the 
methods  of  overall  system  integration  Sufficient  detail 
was  included  to  allow  idor 1 1 f teat  ion  of  possible  system 
component  technologies  ana  to  perform  reliability 
modularity  maintainability,  cost  ai-d  nsk  analysis  upon 
the  system  design  Retrofit  to  oldei  aircraft, 
availability  of  this  system  to  the  single  engine  two  place 
aircraft,  was  Considered 

APT*  NASA-CR- 152025  77/07/00  78N10060 


UTTl  Avionics  namtenance  study 
AUTH  A/OWENS,  P  R  B/STJOHN,  M  R  .  C/lAMB.  F  D  CORP 
Air  Force  Avionics  Lab  Wr ignt -Pat terson  \fB  OH 

ABS  Avionics  maintenance  has  become  a  major  contributor  to  the 
life  cycle  cost  of  weapons  systems  and  this  study  was 
undertaken  to  gain  Insight  into  factors  contributing  to 
the  cost  Of  avionics  maintenanco  To  become  familiar  with 
the  procedures  employe^*  and  operating  conditions 
encountered  In  the  operational  Air  Force,  a  team  from  the 
Air  force  Avionics  Laboratory  visited  several  avionics 
maintenance  squadrons,  along  with  depot  organizat ions  at 
Air  Logistics  Centers  Through  interviews  with  both 
supervisors  and  maintenance  technicians  at  these 
organi zat Ions .  a  f ami  1  tar l zat ion  with  the  working  level 
procedures  was  acquired  Similarities  and  differences  m 
procedures,  personnel,  test  equipment,  complaints  and 
equipment  supported  at  installations  under  different  major 
commands  were  noted  A  wide  range  of  avionics  from  old. 
tube  type  equipment  through  the  latest  solid  state 
equipment  just  being  introduced  into  the  inventory  was 
considered  In  the  selection  of  organizat ions  to  Do 
‘.‘.sited  Oiffiwuiiiws  in  Obtaining  replacement  parts  and 
dissatisfaction  with  test  equipment  were  found  to  be  the 
problems  most  often  voiced  by  maintenance  personnel  To 
persons  from  a  laboratory  environment,  the  age  of  some 
equipment  still  in  use  was  shocking  and  the  necessity  for 
designing  avionics  to  provide  reliable  service  for  IS  to 
20  years  was  strongly  realized  The  need  for  early 
consideration  of  ATE  requirements  to  insure  rapid 
cost-effective  fault  isolation  in  new  avionics  design  is 
emphasized  as  one  conclusion  to  the  study 
RPT*  AD-A0425e8  AFAL-TR-77-90  77/06/00  78N10003 


UTTL  Use  of  commercial  of f • the-shel f  equipment  m 
mill tary  aircraft 

AUTH  A/SCOTT  0  L  CORP  Defense  Systems  Management  School . 
Fort  Belvoir,  VA 

ABS  The  goals  of  the  project  were  to  identify  and  evaluate  the 


B-18 


documents  controMing  the  perfornance  envtronnental 
testing  and  reliabiHty  testing  of  commercle)  avionics 
equipment,  and  to  compare  those  procedures  with 
conventional  niMtary  practice,  and  to  analyze  and 
highlight  those  factors  which  impact  the  decision  of  an 
acquisition  program  nanan«r  whn  o  considering  the  u'e  of 
commercial  equipment  in  ml)'*ery  aircraft 
RPT»  40-AO33818  76/05/00  77N23t03 


UTTL  A  lessons- 1  earned  study  of  art  Airborne  UhF  radio 
program 

AUTh  A/MCOLIN,  K  A  CQRP  Air  Force  Inst  of  Tech  . 

Wright -Patterson  AFB,  OM  CSS  (School  of  Engineering  ) 

A6S  A  study  was  made  on  the  evolution  of  the  major  subsystem 
program  Of  primary  concern  was  the  manner  in  which  a 
program  is  in'tiated  the  changes  which  it  undergoes  and 
the  reason  for  the  changes  The  intent  of  the  study  was 
to  ex*ract  lessons  learned  which  night  be  of  benefit  to 
others  in  subsystem  program  managonent  The  study  was 
accomplished  by  reviewing  program  data  and  interviewing 
key  participants  This  data  was  reviewed  through  an 
hypothesi2ed  framework  of  inittel  attempts  regrouping 
nature  ar-^  direction  solicitation,  evaluation  and  award 
of  a  subsystem  program  This  study  has  shown  the 
difficulty  in  establishing  a  basis  of  action  for  a 
subsystem  program,  the  subjective  nature  ot  requirements 
the  difficulty  m  building  competition  and  opennandedness 


into  a  program,  and  the  complexity  of  a  program  even  when 
It  IS  a  subsystem  In  addition.  It  was  shown  that  the 
hypothesized  framework  was  realistic  in  reviewing  the 
evolution  of  a  subsystem  program 
RPTa  A0-A021264  CSM/SM/75S-6  75/09/00  76N29473 


UTTL  Models  and  methodology  for  life  cycle  cost  and  test 
and  evaluation  analysis 

AUIH  A/ANOERSON.  R  H  ,  8/DIXON  T  E  ,  C/COUCH,  R  F  .  JR 

0/NEWHART,  w  M  JR  CORP  Office  Of  the  Assistant  for 
Study  Support,  Kirtland  AF6,  NM 

ASS  This  report  documents  various  models  and  methodology  which 
were  developed  du  ing  the  course  of  some  analytical 
studies  on  life  cycle  cost  and  test  and  evaluation  These 
studies  were  conducted  by  the  Office  of  the  Assistant  for 
Study  Support  (OAS)  at  the  request  of  OCS/Oevelopment 
elans  Headquarters  AFSC  The  objectives  of  the  study  were 
to  Investigate  *he  present  methods  of  wubsyster 
reliability  specification  and  Identify  limitations 
associated  with  those  methods  investigate  new  and 
innovative  techniques  for  subsystem  reliability  management 
and  Identify  benefits  to  be  derived  in  terns  of  higher 
porformance/lower  costs,  and,  develop  models  and 
methodology  applicable  to  life  cycle  cost  and  test  and 
evaluation  analyses  (Modified  author  abstract) 

ftPT*  AO-782182  OAS-Tfl-73-6  73/07/00  74N345I6 
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